Выбор лидера

1) Зачем нужен лидер и когда он вообще оправдан

Лидер — узел, имеющий эксклюзивное право выполнять критичные действия: запуск крона/ETL, координация шардов, распределение ключей, изменение конфигурации. Он упрощает инварианты («один исполнитель»), но добавляет риски (SPOF, пере-выборы, лаг).

• нужна единственность исполнения (например, биллинг-агрегатор раз в минуту);
• требуется серилизация изменений (реестр конфигураций, распределенные блокировки);
• кластерный протокол предполагает лидерскую репликацию (Raft).

• проблему решает идемпотентность и порядок по ключу;
• можно распараллелить через work-stealing/очереди;
• «лидер» становится единственной узкой точкой (широкий фан-ин).

2) Базовая модель: lease + кворум + эпоха

Термины

Lease (аренда): лидер получает право на T секунд; обязан продлевать.
Heartbeat: периодическое продление/сигнал «жив».
Epoch / term (эпоха, срок): монотонно растущий номер лидерства. Помогает распознать «старых» лидеров.
Fencing token: тот же монотонный номер, который проверяет потребитель ресурса (БД/хранилище) и отвергает операции старого лидера.

Инварианты

В любой момент не более одного действительного лидера (safety).
При сбое возможен прогресс: за разумное время избирается новый (liveness).
Операции лидера сопровождаются эпохой; синки принимают только более новые эпохи.

3) Обзор алгоритмов и протоколов

3.1 Raft (лидерская репликация)

Состояния: Follower → Candidate → Leader.
Таймеры: random election timeout (джиттер), RequestVote; лидер держит AppendEntries как heartbeat.
Гарантии: кворум, отсутствие split-brain при стандартных предпосылках, журнал с логической монотонией (term/index).

3.2 Paxos/Single-Decree / Multi-Paxos

Теоретическая основа консенсуса; на практике — вариации (e.g., Multi-Paxos) с «выбранным координатором» (аналог лидера).
Сложнее для прямой реализации; чаще используются готовые реализации/библиотеки.

3.3 ZAB (ZooKeeper Atomic Broadcast)

Механизм ZK: лидерская репликация журнала с фазами восстановления; эпохи (zxid) и последовательные эфемерные узлы для примитивов вроде лидерства.

3.4 Bully / Chang–Roberts (кольца/монарх)

«Учебные» алгоритмы для статических топологий без кворума. Не учитывают частичные сбои/разделения сети — не применяйте в проде.

4) Практические платформы

4.1 ZooKeeper

Паттерн EPHEMERAL_SEQUENTIAL: процесс создает `/leader/lock-XXXX`, минимальный номер — лидер.
Потеря сессии ⇒ узел исчезает ⇒ пере-выбор мгновенен.
Справедливость через ожидание «предшественника».

4.2 etcd (Raft)

Нативное лидерство на уровне самого кластера; для приложений — etcd concurrency: `Session + Mutex/Election`.
Lease-ID с TTL, keepalive; можно хранить эпоху в значении ключа.

4.3 Consul

`session` + `KV acquire`: кто удерживает ключ — тот и лидер. TTL/сердцебиение на сессии.

4.4 Kubernetes

Leases coordination API (`coordination.k8s.io/v1`): ресурс `Lease` c `holderIdentity`, `leaseDurationSeconds`, `renewTime`.
Клиентская библиотека `leaderelection` (client-go) реализует захват/продление; идеальна для лидера-подов.

5) Как построить «безопасного» лидера

5.1 Храните эпоху и fencing

Каждое лидерство увеличивает epoch (например, ревизия etcd/ZK zxid или отдельный счетчик).

sql
UPDATE cron_state
SET last_run = now(), last_epoch =:epoch
WHERE name = 'daily-rollup' AND:epoch > last_epoch;

Старый лидер (после split-brain) будет отвергнут.

5.2 Тайминги

`leaseDuration` ≥ `2–3 × heartbeatInterval + сеть + p99 GC-пауза`.
Election timeout — рандомизировать (джиттер), чтобы кандидаты не коллизились.
При потере продления — немедленно прекратить критичные операции.

5.3 Идентичность

`holderId = node#pid#startTime#rand`. При обновлении/снятии сверяйте тот же holder.

5.4 Наблюдатели (watchers)

Все последователи подписаны на изменения `Lease/Election` и начинают/останавливают работу в соответствии с состоянием.

6) Реализации: фрагменты

6.1 Kubernetes (Go)

go import "k8s. io/client-go/tools/leaderelection"

lec:= leaderelection. LeaderElectionConfig{
Lock: &rl. LeaseLock{
LeaseMeta: metav1. ObjectMeta{Name: "jobs-leader", Namespace: "prod"},
Client:  coordClient,
LockConfig: rl. ResourceLockConfig{Identity: podName},
},
LeaseDuration: 15 time. Second,
RenewDeadline: 10 time. Second,
RetryPeriod:  2 time. Second,
Callbacks: leaderelection. LeaderCallbacks{
OnStartedLeading: func(ctx context. Context) { runLeader(ctx) },
OnStoppedLeading: func() { stopLeader() },
},
}
leaderelection. RunOrDie(context. Background(), lec)

6.2 etcd (Go)

go cli, _:= clientv3. New(...)
sess, _:= concurrency. NewSession(cli, concurrency. WithTTL(10))
e:= concurrency. NewElection(sess, "/election/rollup")
_ = e. Campaign (ctx, podID )//blocking call epoch: = sess. Lease ()//use as part of fencing defer e. Resign(ctx)

6.3 ZooKeeper (Java, Curator)

java
LeaderSelector selector = new LeaderSelector(client, "/leaders/rollup", listener);
selector. autoRequeue();
selector. start(); // listener. enterLeadership () performs leader work with try/finally

7) Пере-выборы и деградация сервиса

Резкие флаппинги лидера → «рыбья косточка» в графиках. Лечится увеличением leaseDuration/renewDeadline и устранением GC/CPU-пил.
На период пере-выбора включайте brownout: снижайте интенсивность фоновых задач или полностью замораживайте их до подтвержденного leadership.
Для долгих джобов делайте чекпоинты + идемпотентный докат после смены лидера.

8) Split-brain: как не попасть

Используйте CP-хранилища (etcd/ZK/Consul) с кворумом; без кворума лидера взять нельзя.
Никогда не строите лидерство на AP-кэше без арбитра кворума.
Даже в CP-модели держите fencing на уровне ресурса — это страховка от редких нештатных сценариев (паузы, подвисшие драйверы).

9) Наблюдаемость и эксплуатация

Метрики

`leadership_is_leader{app}` (gauge 0/1).
`election_total{result=won|lost|resign}`.
`lease_renew_latency_ms{p50,p95,p99}`, `lease_renew_fail_total`.
`epoch_value` (монотонность по кластерам).
`flaps_total` — число смен лидера за окно.
Для ZK/etcd: лаг репликации, здоровье кворума.

Алерты

Частая смена лидера (> N за час).
Провалы продления `renew`/высокий p99.
Несходимость epoch (две разные эпохи в разных узлах).
Нет лидера дольше X сек (если бизнес не допускает).

Логи/трейсы

Линкуйте события: `epoch`, `holderId`, `reason` (lost lease, session expired), `duration_ms`.

10) Тест-плейбуки (Game Days)

Partition: разорвите сеть между 2 зонами — лидерство допускается только в кворумной части.
GC-stop: искусственно остановите лидер на 5–10с — должен потерять арендy и прекратить работу.
Clock skew/drift: убедитесь, что корректность не зависит от wall-clock (fencing/epoch спасают).
Kill -9: внезапный крэш лидера → новый лидер за ≤ leaseDuration.
Slow storage: замедлите диски/лог Raft — оцените время выборов, отладьте тайминги.

11) Анти-паттерны

«Лидер» через Redis `SET NX PX` без fencing и без кворума.
`leaseDuration` меньше p99 длительности критичной операции.
Остановка/продолжение работы после потери лидерства («еще минутку доделаю»).
Отсутствие джиттера в election-таймерах → шторм выборов.
Единая длинная джоба без чекпоинтов — каждый флап приводит к повтору с нуля.
Тесная связь лидерства и маршрутизации трафика (sticky) без fallback — поды при флапе получают 5xx.

12) Чек-лист внедрения

• Выбран арбитр кворума: etcd/ZK/Consul/K8s Lease.
• Храним и передаем epoch/fencing во все побочные эффекты лидера.
• Настроены тайминги: `leaseDuration`, `renewDeadline`, `retryPeriod` с запасом на сеть/GC.
• Встроены watchers и корректная остановка работ при потере лидерства.
• Лидерские задачи идемпотентны и чекпоинтятся.
• Метрики/алерты и логирование `epoch/holderId` включены.
• Проведены game days: partition, GC-stop, kill, clock skew.
• Документированы политики: кто/что делает лидер, кто может его заменить, как резолвить конфликты epoch.
• План деградации: что делает система без лидера.
• Тест производительности: flaps под нагрузкой не рушат SLO.

13) FAQ

Q: Можно ли лидерство строить без кворума?
A: В проде — нет. Нужен CP-компонент (кворум) или облачный сервис с эквивалентными гарантиями.

Q: Зачем epoch, если есть lease?
A: Lease обеспечивает живучесть, но не защищает от «старого лидера» после разделения/пауз. Epoch/fencing делает эффекты старого лидера недействительными.

Q: Какие дефолты таймингов в K8s?
A: Часто используют `LeaseDuration≈15s`, `RenewDeadline≈10s`, `RetryPeriod≈2s`. Подберите под вашу p99-нагрузку и GC.

Q: Как тестировать лидерство локально?
A: Запустите 3–5 инстансов, эмулируйте сеть (tc/netem), паузы (SIGSTOP), убивайте лидера (SIGKILL), проверяйте метрики/логи/эпохи.

Q: Что делать с долгими задачами при смене лидера?
A: Чекпоинт + идемпотентный докат; при потере лидерства — немедленный стоп и освобождение ресурсов.

14) Итоги

Надежный выбор лидера — это кворумный арбитр + дисциплина эпох. Держите лидерство как аренду с heartbeat, бейте все эффекты fencing-токеном, настраивайте тайминги с запасом, делайте задачи лидера идемпотентными и наблюдаемыми, регулярно проигрывайте сбои. Тогда «один и только один» исполнитель будет не лозунгом, а гарантией, устойчивой к паузам, сетевым капризам и человеческим ошибкам.