Email or username:

Password:

Forgot your password?
Aleksei � Matiushkin's posts Post Back to profile
Top-level
Kirill

@mudasobwa

Либо я не понял вопрос, либо по FLP такое сделать нельзя. (консенсус эквивалентен детектору сбоев)

2 June at 13:20 | Wall-to-wall | Open on lor.sh
11 comments
Aleksei � Matiushkin

@kirillgrachoff ну, не вообще нельзя ни на микросекунду потерять соединение, но переконнектиться надо в пределах миллисекунд, если нода померла

2 June at 14:30 | Open on mastodon.social
Kirill

@mudasobwa
Решения лучше чем "возьмём консенсус и подтюним heartbeat'ы до 10ms" придумать не могу. Если в каждый момент времени нужно не более 1 процесса (нельзя разъезжаться по состоянию), то без консенсуса/leader election тут не обойтись. По FLP возможен live lock, так что может быть такое (в теории), что сервиса не будет очень долго.

2 June at 16:40 | Open on lor.sh
Aleksei � Matiushkin

@kirillgrachoff

> Если […] не более 1 процесса […] без консенсуса/leader election тут не обойтись

Вот уж воистину, во многой мудрости — много печали. Консенсус тут не нужен, как следствие — FLP impossibility вообще ни при чем.

Мне не нужно ни о чем договариваться. Нода №1 померла — нода №2 это увидела и начала сосать данные вместо нее, а в дороге сообщила нодам №№3–N, что теперь она главная.

Алгоритм «кто-первый-встал-того-и-тапки» — не нуждается в консенсусе и потому FLP не подвержен.

2 June at 16:51 | Open on mastodon.social
Kirill

@mudasobwa
В таком случае возможно 2 лидера (точнее, 2 процесса, каждый из которых считает себя лидером и принимает операции на запись). Если это подходит, то ладно, FLP и консенсус реально не нужны.

3 June at 7:07 | Open on lor.sh
Aleksei � Matiushkin

@kirillgrachoff нет, невозможно; только в условиях сплита сети, но там и консенсус облажается, и в ECS обычно сплитов все-таки не бывает.

3 June at 7:52 | Open on mastodon.social
Kirill

@mudasobwa
В случае сплита сети консенсус не облажается: majority будет в одной половине. Да, если сплит будет каким-то жёстким, консенсус встанет.

Ладно, предположим, что сплита быть не может. (Это, конечно, одно из нескольких заблуждений в распределённых системах, но ладно)

Возможно, я что-то не понимаю. Для меня пока модель выглядит так:
1. Нода понимает, что лидер лёг.
2. Нода бежит рассказывать всем, что она лидер.

1. Действительно правильный failure detector эквивалентен консенсусу. Если хватит просто какого-то приближения, то хватит и heartbeat'ов.
2. Если нода бежит рассказывать близнецам, что она лидер, то мы переизобретаем консенсус. Не надо это делать. Есть single decree Paxos (надеюсь, не ошибся в названии). Если же она идёт в какой-то внешний сервис, то в этом внешнем сервисе консенсус.

В общем, возможно и невозможно сделать быстрый leader election без погружения в недра системы.

@mudasobwa
В случае сплита сети консенсус не облажается: majority будет в одной половине. Да, если сплит будет каким-то жёстким, консенсус встанет.

Ладно, предположим, что сплита быть не может. (Это, конечно, одно из нескольких заблуждений в распределённых системах, но ладно)

Возможно, я что-то не понимаю. Для меня пока модель выглядит так:
1. Нода понимает, что лидер лёг.
2. Нода бежит рассказывать всем, что она лидер.

3 June at 8:40 | Open on lor.sh
Kirill

@mudasobwa
А где будет записано, что "первым встал" процесс №2?

3 June at 7:08 | Open on lor.sh
Aleksei � Matiushkin

@kirillgrachoff конкретно в моем случае — BEAM cluster — нигде экплицитно это записано не будет, просто я запускаю на всех нодах процесс с именем `{:global, Consumer}` и первый запустится и вернет `pid`, а все последующие попытки получат обратно `{:error, {:already_started, pid}}` и всё.

Тут за меня BEAM все сам сделает, проблема только в мониторинге.

github.com/am-kantox/solo/blob

3 June at 7:56 | Open on mastodon.social
Kirill

@mudasobwa
Значит, в BEAM написан консенсус (либо у них есть точка роста, и можно им нанести там пользу). Тогда где-нибудь в BEAM Cookbook (не знаю, есть ли такая) написано, как следить за тем, что процесс не упал.

(у меня 0 знаний, кроме тех, что BEAM - это что-то про Erlang и поднятие акторов)

3 June at 8:44 | Open on lor.sh
Aleksei � Matiushkin

@kirillgrachoff у меня нет никаких проблем с моей экосистемой; я уже давно написал код, который работает, протестирован, и вообще с ним все хорошо.

Мой вопрос звучал так: как сие решают на джаве, го и ноде.

Ответ «консенсус» — это хороший ответ, я приму его к сведению. На го, скорее всего, иначе действительно никак, но везде, где есть виртуальная машина — консенсус в хер не вперся, VM вполне себе в курсе, что, где и как.

А когда падает VM, об этом тут же узнает сервер соединений, и тоже ок.

3 June at 9:07 | Open on mastodon.social
Kirill

@mudasobwa
А, понял.

Либо etcd, либо Zookeeper часто используют, если это не критично. Если критично, то велосипедят свой консенсус на C++.

3 June at 9:13 | Open on lor.sh
Go Up