Как процессы супервизора контролируют процессы? Можно ли сделать то же самое на JVM? - PullRequest
8 голосов
/ 19 июля 2009

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

Как Erlang осуществляет этот мониторинг, особенно в распределенном сценарии? Как можно быть уверенным, что процесс действительно умер? Это сердце бьется? Что-то встроено в среду выполнения? Что, если сетевой кабель отключен - предполагается ли, что другие процессы умерли, если он не может связаться с ними? и т.д.

Я думал о том, как добиться такой же отказоустойчивости и т. Д., Как утверждал Эрланг в JVM (скажем, на Java или Scala). Но я не был уверен, что для этого потребуется поддержка, встроенная в JVM, а также Erlang. Я еще не нашел определения того, как Эрланг это делает, хотя для сравнения.

Ответы [ 4 ]

5 голосов
/ 20 июля 2009

Erlang OTP Supervision обычно не выполняется между процессами на разных узлах. Это бы сработало, но лучше всего делать это по-другому.

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

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

Если супервизор и процесс выполняются локально, сбой и сигнал для супервизора в значительной степени мгновенны. Он опирается на функцию, при которой аварийный сбой распространяется и на связанные процессы, которые также выходят из строя, если только они не перехватывают выходы.

0 голосов
/ 21 июля 2009

Erlang является открытым исходным кодом, что означает, что вы можете загрузить исходный код и получить окончательный ответ о том, как Erlang это делает.

Как Erlang осуществляет этот мониторинг, особенно в распределенном сценарии? Как можно быть уверенным, что процесс действительно умер? Это сердце бьется? Что-то встроено в среду выполнения?

Я полагаю, это сделано во время выполнения BEAM. Когда процесс умирает, сигнал отправляется всем процессам, связанным с ним. Смотрите главу 9 из Программирование Erlang для полного обсуждения.

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

В Erlang вы можете контролировать узел и получать сообщения {node_up, Node} и {node_down, Node}. Я предполагаю, что они также будут отправлены, если вы больше не можете общаться с узлом. Как вы справляетесь с ними, зависит от вас.

0 голосов
/ 19 июля 2009

Я думаю, что вы имеете в виду под супервизором процесс portmapper. Вы можете использовать портмейпер / инфраструктуру Erlang через JInterface - таким образом, вы не будете изобретать велосипед заново - на случай, если вы все еще захотите его, вы получите как минимум все интерфейсы, описанные там.

0 голосов
/ 19 июля 2009

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

...