Raft в реальном мире: partition, медленный диск и клиентская маршрутизация

Network partition разделяет твой 5-нодовый etcd-кластер: 3 ноды в DC A, 2 ноды в DC B. Клиенты начинают получать write-ошибки с одной стороны. Это баг? Или именно так Raft и должен работать?

Поведение при partition: minority останавливается

Когда partition изолирует minority нод (меньше большинства), они не могут коммитить или выбирать лидера. Они циклически проводят неудачные выборы, возвращая ошибки любому подключившемуся клиенту. Majority-сторона продолжает нормально.

Это CP-поведение в смысле CAP: Raft выбирает консистентность над доступностью. Minority-сторона отказывает от сервиса, не рискуя двумя одновременными лидерами с конфликтующими коммитами.

После восстановления partition: stale-ноды minority видят больший term в первом сообщении от majority-стороны, переходят в follower, обновляют term и догоняют лог через AppendEntries. Никаких потерь данных, никакого раздвоения состояния.

Trace partition: лидер в minority

Более тонкий сценарий: сам лидер оказывается на minority-стороне.

Клиентская маршрутизация

Только лидер может коммитить записи. Стратегии маршрутизации клиентов:

1. Redirect: любой follower, получивший запись, отвечает адресом текущего лидера. Клиент ретраит к тому адресу. Типичный паттерн в etcd, Consul, TiKV.
2. Leader cache: клиенты кешируют последнего известного лидера и идут к нему напрямую; при неудаче откатываются к любой ноде.
3. Proxy: балансировщик нагрузки отслеживает лидера через health API кластера.

Задержка redirect обычно 1–5 мс на редком промахе. В steady state записи идут напрямую к лидеру.

Консистентность чтения: линеаризуемые чтения должны идти через лидера (ReadIndex или lease — разбираются в следующем уроке). Eventually-consistent чтения могут идти к любому follower-у. Application-слой выбирает per query.

Три production-failure

1. Медленный fsync диска. Каждое закоммиченное entry требует как минимум одного fsync на лидере и одного на каждом подтверждающем follower-е. На NVMe с battery-backed cache fsync занимает 50–100 мкс. На cloud-объёмах (EBS gp3, GCP balanced PD) — 1–3 мс. Если fsync лидера начинает превышать heartbeat-интервал, follower-ы таймаутят до того, как лидер подтвердит их AppendEntries, и стартуют выборы. Новый лидер попадает на ту же disk-проблему — цикл повторяется. Фикс: dedicated NVMe для Raft WAL, никогда shared cloud-объёмы.

2. Network jitter. Краткий congestion или потеря пакетов обрывают heartbeat-ы и триггерят выборы, хотя кластер в основном здоров. Кластер испытывает 150–300 мс недоступности без длительных последствий. Pre-vote (разбирается в следующем уроке) митигирует это, требуя dry-run перед увеличением term.

3. Дрейф часов при lease read. Если часы лидера убегают вперёд follower-ов, он может растянуть своё lease-окно за фактический heartbeat round и обслуживать чтения, которые уже потеряли lease — stale-данные возвращаются как актуальные. NTP-синхронизация всех нод — требование корректности для lease read, а не просто гигиена.