awesome-everything EN
↑ Обратно к восхождению

Распределённые системы

Выборы лидера в Raft: таймауты, правила голосования и четыре свойства безопасности

Суть Как рандомизированные таймауты предотвращают повторные split vote, почему правило completeness лога сохраняет закоммиченные entry при смене лидера, и четыре инварианта, делающих Raft корректным.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на middle-высоте — в небе
◷ 14 min

Пять follower-ов одновременно замечают, что лидер молчит. Все пятеро стартуют выборы. Каждый голосует за себя. Никто не побеждает. Цикл повторяется. Именно поэтому Raft использует рандомизированные таймауты — и почему правило голосования тоньше, чем “первый пришёл — первый подан”.

Election timeout и heartbeat-ы

Лидер утверждает свою власть, отправляя heartbeat-ы AppendEntries каждому follower-у с фиксированным интервалом — обычно 50 мс. У каждого follower-а есть election timeout, сбрасываемый каждым валидным heartbeat-ом. Если таймаут срабатывает (heartbeat не получен), follower считает лидера мёртвым и запускает выборы.

Таймаут рандомизирован — обычно в диапазоне 150–300 мс. Без рандомизации все follower-ы таймаутили бы одновременно, каждый голосовал за себя, и голос бы раздробился. При достаточно широком диапазоне с высокой вероятностью один follower срабатывает первым, отправляет RequestVote всем остальным и собирает большинство до того, как кто-то другой таймаутит. Ничьи всё ещё возможны, но редки; любая ничья просто начинает новый term, и новый случайный таймаут быстро её разрешает.

ТаймаутКто срабатывает первымРезультат
Фиксированный 200 мсВсе 5 одновременноSplit vote, term потрачен впустую
Случайный 150–300 мсB на 163 мсB побеждает до истечения таймаутов других
Случайный, не повезлоB на 157 мс, C на 159 мсSplit vote, новый term, быстро разрешается

Правило голосования RequestVote

Нода отдаёт голос в RequestVote только если:

  1. Она ещё не голосовала в этом term (один голос на term на ноду).
  2. Лог candidate-а как минимум так же актуален, как собственный лог voter-а.

“Как минимум так же актуален” сравнивается по: больший lastLogTerm побеждает; при равных term-ах побеждает больший lastLogIndex. Это правило — ключ к безопасности.

Почему правило completeness лога важно

Без проверки up-to-date candidate со stale-логом мог бы выиграть выборы и стать лидером, не имея закоммиченных entry. Эти entry были бы перезаписаны, нарушая гарантию, что закоммиченное entry сохраняется навсегда.

Аргумент пересечения кворумов объясняет, почему правило работает: каждое закоммиченное entry было подтверждено большинством. Любой election-кворум пересекается с этим commit-кворумом хотя бы в одной ноде. Через эту общую ноду candidate должен иметь закоммиченное entry (иначе voter откажет). Вместе пересечение кворумов и правило completeness лога дают Leader Completeness: каждый лидер term T+1 имеет все entry, закоммиченные в term-ах 1–T.

Четыре свойства безопасности

Доказательство корректности Raft сводится к четырём инвариантам:

  1. Election Safety — максимум один лидер на term. Следует из “один голос на ноду на term + требуется большинство”.
  2. Leader Append-Only — лидер никогда не перезаписывает и не удаляет свои log entry; только дописывает.
  3. Log Matching — если два лога имеют общий entry на index i с term t, они идентичны для всех index до i включительно. Следует из проверки целостности AppendEntries.
  4. Leader Completeness — любое entry, закоммиченное в каком-то term, есть в логе каждого лидера более высоких term-ов. Следует из пересечения кворумов + правила голосования.

State Machine Safety (выводится): никакие две ноды никогда не применяют разные команды на одном index.

Викторина

Зачем Raft рандомизирует election timeout (150–300 мс) вместо фиксированного значения?

Викторина

Почему правило голосования RequestVote требует, чтобы лог candidate-а был как минимум так же актуален, как у voter-а?

Проследи
1/5

Проследи чистые выборы лидера после его краша.

1
Step 1 of 5
Сетап: 5-нодовый кластер A, B, C, D, E. A — лидер term 7. A падает.
2
Locked
Таймер B срабатывает первым на 187 мс. Что делает B?
3
Locked
C, D, E получают RequestVote. Они проверяют: голосовал ли я в term 8? Лог B как минимум так же актуален, как мой?
4
Locked
B собирает 3 голоса (себя + C + D). Что дальше?
5
Locked
A возвращается online со stale term 7.
Вспомните перед уходом
  1. 01
    Почему Raft требует большинства для выборов, а не просто 2 из 5?
  2. 02
    Нода вернулась после 10 минут offline. У неё lastLogTerm=5, lastLogIndex=200. Кластер на term 12, лидер имеет lastLogIndex=9500. Может ли эта нода выиграть выборы?
  3. 03
    В чём разница между Election Safety и Leader Completeness?
Итог

Raft предотвращает повторные split vote рандомизацией election timeout — первый срабатывает follower скорее всего собирает большинство до того, как остальные вообще стартуют. Правило голосования RequestVote требует от candidate-ов иметь логи как минимум так же актуальные, как у любого voter-а — вместе с пересечением кворумов это гарантирует, что выигравший лидер имеет каждое ранее закоммиченное entry (Leader Completeness). Четыре свойства безопасности — Election Safety, Leader Append-Only, Log Matching и Leader Completeness — вместе гарантируют, что никакие две ноды никогда не применяют разные команды на одном index. Типичные выборы лидера на здоровом кластере разрешаются за 100–500 мс.

Связанные уроки
встречается в178
Продолжить восхождение ↑Raft в реальном мире: partition, медленный диск и клиентская маршрутизация
хоткеи развернуть
поиск
K
пред. пьеса
k
след. пьеса
j
тиры
t
это меню
?
sources3
expand
  1. 01
  2. 02
  3. 03

Trademarks belong to their respective owners. Editorial reference only.