Контекст
Консенсус: Paxos и Raft
Leader election - прикладной слой поверх consensus/coordination механизмов.
Leader election нужен, когда системе нужен единственный активный координатор. Практика показывает: выбор лидера сам по себе не решает проблему, если не закрыты split-brain, fencing и корректные failover semantics.
Когда нужен лидер
- Single-writer операции (например, scheduler, allocator, ownership map).
- Контроль фоновых задач, где должен работать только один active coordinator.
- Failover stateful компонентов и управление leader-only действиями.
- Распределенные lock/lease сценарии в control plane.
Механизмы election
Lease-based election
Лидер удерживает lease и регулярно продлевает его. При истечении lease другой кандидат может стать лидером.
Clock skew и network jitter могут вызвать split-brain без fencing tokens.
Consensus-based election (Raft/Paxos)
Лидер выбирается через кворум и term/version semantics. Самый надёжный путь для критичных систем.
Сложность реализации и операционные требования к quorum health.
Coordination-service election
Выбор лидера через ZooKeeper/etcd/Consul primitives (ephemeral nodes, compare-and-swap, distributed locks).
Зависимость от доступности coordination-сервиса и корректной конфигурации таймаутов.
Time
Clock Synchronization
Lease-based leadership без time discipline часто приводит к split-brain.
Практические реализации
Raft
Election timeout + majority vote + term. Стандарт де-факто для многих control plane систем.
ZooKeeper
Ephemeral sequential znode pattern: самый младший znode становится лидером.
etcd
Leases + Compare-And-Swap + lock API. Часто используется для leadership в cloud-native системах.
Kubernetes
Lease objects в coordination API для controller leader election.
Split-brain защиты
Fencing tokens: каждый новый лидер получает monotonically increasing token для защиты downstream write path.
Leader-only operations проверяют term/token перед выполнением побочных эффектов.
Stale leader detection: heartbeat + session expiry + fast revoke.
Read-only/degraded mode при потере quorum вместо небезопасного dual-writer поведения.
Практический чеклист
- В системе явно определены leader-only и follower-safe операции.
- Есть гарантированный способ предотвратить split-brain side effects (fencing/version checks).
- Election-timeouts согласованы с реальными network/GC характеристиками.
- Есть тесты на partition, delayed packets, process pause/restart.
- Failover проверяется регулярно через game day сценарии.
Частый anti-pattern: есть election, но нет fencing - и система всё равно делает dual writes.
Связанные главы
Консенсус: Paxos и Raft
Теоретическая и практическая база leader election в quorum-системах.
Clock Synchronization
Lease-based election чувствителен к time assumptions и drift.
Репликация и шардинг
Лидер часто отвечает за primary-write path и координацию реплик.
Testing Distributed Systems
Как валидировать election/failover при реальных сбоях и partition.
Distributed Transactions: 2PC и 3PC
Coordinator транзакции - отдельный случай лидерской координации.