Erlang процессы супервизора

Question

Я интенсивно изучал Эрланг, и после окончания "Программирования Эрланга" от Джо Армстронга есть одна вещь, к которой я продолжаю возвращаться.

По моему мнению, супервизор порождает один процесс на каждого дочернего обработчика. Таким образом, каждый объявленный обработчик типа gen_server будет выполняться как отдельный процесс.

Что произойдет, если вы создаете крошечный веб-сервер и хотите, чтобы каждый запрос был отдельным процессом. Вы все еще соответствуете принципам OTP и используете каким-либо образом gen_server (как?), Или вы создаете свое собственное поведение?

Как Ковбой справляется с этим, например.? Он все еще использует gen_server?

Answer 1

tl;dr: Я считаю, что попытка выяснить "правильную" структуру надзора в начале проекта является формой преждевременной оптимизации.

"Правильный" способ разработки дерева контроля зависит от того, что делают рабочие части вашего приложения. В случае с веб-сервером я, вероятно, сначала изучу что-то вроде:

• главный руководитель (единственное число)
  • супервизор службы данных (по одному на тип услуги)
    • рабочий пул (все работники в рамках службы поддержки)
  • супервизор клиентских подключений (один)
    • рабочий пул соединений (или по одному на соединение, нужно поиграть с ним, чтобы решить)
  • логический супервизор (в зависимости от обстоятельств - существенная разница здесь в зависимости от предметной области)
    • работники или руководители (в зависимости от обстоятельств - должны изучить / знать проблемную область, чтобы иметь представление о том, как это должно быть структурировано)

Так что это несколько работников на тип супервизора на нижнем уровне. Я не использовал Ковбой, поэтому я не знаю, как это организовано. Я хочу подчеркнуть, что хотя механизмы обработки служб данных, обслуживающих веб-страницы, относительно тривиальны, часть системы, которая фактически выполняет основную работу по решению проблем, может и не быть, и это будет диктовать все, что интересно система.

Плохо смешивать биты решения проблем в одном модуле с битами отображения в сети или обработки соединений. В идеале вы должны иметь возможность использовать одни и те же логические блоки в собственном приложении, веб-приложении и сетевом сервисе без каких-либо изменений.

В конечном итоге ответ на вопрос о том, должны ли вы иметь руководителей 1:1 для работников или 1:n, зависит от того, что вы делаете, и какая стратегия перезапуска дает вам наилучший баланс между восстановлением до известного согласованного состояния, задержкой, ощущаемой пользователем, и ресурсом. использование.

Одна из моих любимых вещей в Erlang заключается в том, что я могу начать с наивной структуры супервизора, подобной приведенной выше, играть с ней до тех пор, пока не увижу, где она не очень хорошая, и довольно легко переключать вещи и экспериментировать с альтернативами без существенного изменения моей системы., (То же самое касается игры с альтернативными представлениями данных, если вы пишете правильные абстракции вокруг них.) Итак, во-первых, получите что-то, что работает в тестировании. Затем загрузите его и посмотрите, сможете ли вы его сломать. Затем начните беспокоиться о деталях, после того как вы поймете, где проблемы на самом деле.

Answer 2

Это общий шаблон для порождения одного сервера на клиента в erlang. Затем вы будете использовать супервизор, используя стратегию simple_one_to_one для дочерних серверов. Это позволяет попросить сервер запустить сервер on_demand. Обычно это используется, когда вы не знаете, сколько процессов вам потребуется, и когда процессы независимы (сбой одного процесса не должен влиять на другой).

На сайте learningyousomeerlang.com есть очень хорошая информация ( глава LYSE supervisor). Весь сайт стоит прочитать.