|
Top-level
 @kirillgrachoff конкретно в моем случае — BEAM cluster — нигде экплицитно это записано не будет, просто я запускаю на всех нодах процесс с именем `{:global, Consumer}` и первый запустится и вернет `pid`, а все последующие попытки получат обратно `{:error, {:already_started, pid}}` и всё. Тут за меня BEAM все сам сделает, проблема только в мониторинге. https://github.com/am-kantox/solo/blob/main/lib/solo.ex#L179 3 comments
@kirillgrachoff у меня нет никаких проблем с моей экосистемой; я уже давно написал код, который работает, протестирован, и вообще с ним все хорошо. Мой вопрос звучал так: как сие решают на джаве, го и ноде. Ответ «консенсус» — это хороший ответ, я приму его к сведению. На го, скорее всего, иначе действительно никак, но везде, где есть виртуальная машина — консенсус в хер не вперся, VM вполне себе в курсе, что, где и как. А когда падает VM, об этом тут же узнает сервер соединений, и тоже ок. @mudasobwa Либо etcd, либо Zookeeper часто используют, если это не критично. Если критично, то велосипедят свой консенсус на C++. |
Gregory's Server
@mudasobwa
Значит, в BEAM написан консенсус (либо у них есть точка роста, и можно им нанести там пользу). Тогда где-нибудь в BEAM Cookbook (не знаю, есть ли такая) написано, как следить за тем, что процесс не упал.
(у меня 0 знаний, кроме тех, что BEAM - это что-то про Erlang и поднятие акторов)