Позвольте M быть термином Эрланга (), который является сообщением , которое мы отправляем в систему. Одним из очевидных способов обработки M является создание конвейера процессов и очередей. M обрабатывается первым рабочим в конвейере, а затем отправляется в следующую очередь. Затем он обрабатывается следующим рабочим процессом, обрабатывается снова и помещается в очередь. И так до тех пор, пока сообщение не будет полностью обработано.
Возможно, не столь очевидный способ - определить процесс P, а затем передать M на P. Мы отметим это как P(M). Теперь само сообщение является процессом , а не частью данных . P будет выполнять ту же работу, что и рабочие в решении с очередями, но ему не нужно будет платить за вставку M в очереди, снимать его снова и так далее. Когда обработка P(M) завершена, процесс просто завершит свою жизнь. Если передать другое сообщение M', мы просто создадим P(M') и позволим ему обрабатывать это сообщение одновременно. Если мы получим набор процессов, мы сделаем [P(M) || M <- Set] и т. Д.
Если P требуется выполнить синхронизацию или обмен сообщениями, он может сделать это без необходимости «олицетворять» сообщение, поскольку является сообщением. Сравните с подходом «очередь за работником», где работник должен взять на себя ответственность за сообщение, которое приходит вместе с ним. Если P имеет ошибку, произойдет сбой только сообщения P(M), затронутого этой ошибкой. Опять же, в отличие от подхода «рабочая очередь», где сбой в конвейере может повлиять на другие сообщения (в основном, если конвейер плохо спроектирован).
Итак, хитрость в заключении: превратить сообщение в процесс, который становится сообщением.
Идиома «Один процесс на сообщение» и довольно часто встречается в Erlang. Цена и накладные расходы на создание нового процесса достаточно низки, чтобы это работало. Вы можете хотеть некоторую защиту от перегрузки, если используете эту идею. Причина в том, что вы, вероятно, хотите ограничить количество одновременных запросов, чтобы вы контролировали загрузку системы, а не позволяли ей вслепую уничтожать ваши серверы. Одной из таких реализаций является Jobs , созданная Erlang Solutions, см.
https://github.com/esl/jobs
и Ульф Вигер представляет его по адресу:
http://www.erlang -factory.com / конференции / ErlangFactoryLiteLA / колонки / UlfWiger
Как Ульф намекает в разговоре, мы обычно делаем некоторую предварительную обработку вне P, чтобы проанализировать сообщение и передать его в систему Erlang. Но как можно скорее мы превратим сообщение M в job , завернув его в процесс (P(M)). Таким образом, мы сразу получаем преимущества планировщика Erlang.
Существует еще один важный аспект этого выбора: если обработка сообщения занимает много времени, тогда упреждающий планировщик Erlang гарантирует, что сообщения с меньшими потребностями в обработке все же будут обрабатываться быстро. Если у вас ограниченное количество рабочих очередей, многие из них могут быть забиты, что затруднит пропускную способность системы.