@mudasobwa
В таком случае возможно 2 лидера (точнее, 2 процесса, каждый из которых считает себя лидером и принимает операции на запись). Если это подходит, то ладно, FLP и консенсус реально не нужны.
@mudasobwa
В случае сплита сети консенсус не облажается: majority будет в одной половине. Да, если сплит будет каким-то жёстким, консенсус встанет.
Ладно, предположим, что сплита быть не может. (Это, конечно, одно из нескольких заблуждений в распределённых системах, но ладно)
Возможно, я что-то не понимаю. Для меня пока модель выглядит так:
1. Нода понимает, что лидер лёг.
2. Нода бежит рассказывать всем, что она лидер.
1. Действительно правильный failure detector эквивалентен консенсусу. Если хватит просто какого-то приближения, то хватит и heartbeat'ов.
2. Если нода бежит рассказывать близнецам, что она лидер, то мы переизобретаем консенсус. Не надо это делать. Есть single decree Paxos (надеюсь, не ошибся в названии). Если же она идёт в какой-то внешний сервис, то в этом внешнем сервисе консенсус.
В общем, возможно и невозможно сделать быстрый leader election без погружения в недра системы.
@mudasobwa
В случае сплита сети консенсус не облажается: majority будет в одной половине. Да, если сплит будет каким-то жёстким, консенсус встанет.
Ладно, предположим, что сплита быть не может. (Это, конечно, одно из нескольких заблуждений в распределённых системах, но ладно)
Возможно, я что-то не понимаю. Для меня пока модель выглядит так:
1. Нода понимает, что лидер лёг.
2. Нода бежит рассказывать всем, что она лидер.
@kirillgrachoff нет, невозможно; только в условиях сплита сети, но там и консенсус облажается, и в ECS обычно сплитов все-таки не бывает.