Распределённые системы
Raft: тест с выбором ответа
Шесть вопросов поперёк всего юнита. Каждый — решение, которое ты принимаешь, эксплуатируя реальный Raft-кластер (etcd, TiKV, Consul), а не определение для заучивания. Выбери ответ, который senior-инженер защитит на разборе инцидента.
Убедись, что связываешь то, что уроки строили по отдельности: почему majority quorum — требование безопасности, что на самом деле значит «закоммичено», как правило голосования сохраняет историю, почему Raft останавливается при partition и какая ops-дисциплина держит кластер живым.
Кластер из 5 узлов коммитит запись 101 кворумом {A, B, C}. Затем лидер A падает, и новый лидер избирается кворумом {C, D, E}. Почему запись 101 гарантированно переживёт смену term?
Лидер дописывает запись 200 на свой диск и делает fsync, затем падает до того, как хоть один AppendEntries покинул машину. Какое утверждение о записи 200 верно?
Узел возвращается после 30-минутного partition. Всё это время он таймаутил и инкрементировал term, поэтому теперь у него term гораздо выше, чем у живого лидера, но лог устаревший. Что происходит без pre-vote и что меняет pre-vote?
Network partition оставляет текущего лидера на стороне меньшинства — он достаёт лишь 1 из 4 других узлов. Клиенты на стороне лидера получают таймауты записи; сторона большинства избирает нового лидера. Это баг?
Оператору нужно вырастить кластер с 3 до 5 узлов. Он одним атомарным шагом раскатывает новый конфиг из 5 узлов на все узлы, минуя joint consensus. В чём реальный риск?
Кластер показывает рост leader_changes_total до нескольких в минуту, а клиенты видят периодические зависания записи на 200–400 мс. wal_fsync_duration_seconds p99 = 1.8 с. Диагноз и первый фикс?
Стержень юнита — один аргумент безопасности и одна ops-дисциплина. Безопасность: majority quorum гарантирует пересечение любых двух кворумов, поэтому закоммиченную (персистированную majority) запись всегда наследует следующий лидер, а правило полноты лога блокирует устаревшего кандидата; вместе это Leader Completeness, и «закоммичено» всегда значит «персистировано majority». Дисциплина: Raft — это CP, поэтому меньшинство при partition останавливается по дизайну; pre-vote не даёт возвращающимся узлам спровоцировать ненужные выборы; joint consensus не даёт смене состава расколоть кластер; а WAL живёт на выделенном NVMe, чтобы fsync не голодал heartbeat. Почти любой production-инцидент сводится к одному из трёх — обойдённый протокол смены состава, отключённый pre-vote или медленный диск.