Консенсус стоит воспринимать не как знак инженерной зрелости, а как дорогой инструмент для случаев, где системе действительно нужна одна согласованная история состояния.
На практике эта глава помогает отделить сценарии, где Raft или Paxos оправданы, от случаев, где команда покупает лишнюю задержку и сложность без критичного выигрыша в корректности.
На интервью и в архитектурных обсуждениях она особенно сильна, когда вы говорите не только о названиях алгоритмов, но и о цене кворума: задержке записи, восстановлении после отказа, переключении лидера и сложности диагностики.
Практическая польза главы
Практика проектирования
Помогает понять, где действительно нужен контур консенсуса, а где достаточно более простых гарантий.
Качество решений
Даёт способ выбирать между Raft и Paxos с учётом профиля чтения и записи и требований к отказоустойчивости.
Аргументация на интервью
Позволяет объяснить кворум, срок полномочий лидера и фиксацию записи без избыточной теоретизации.
Риски и компромиссы
Фокусирует на цене консенсуса: задержке записи, восстановлении после отказа и сложности отладки.
Связанная книга
Designing Data‑Intensive Applications
Глава о консенсусе и репликации помогает связать журналы команд, кворумы и практические компромиссы отказоустойчивых хранилищ.
В этой главе связывает , , и в один контур принятия решений. Paxos и Raft по-разному организуют роли, сообщения и журнал команд, но оба защищают систему от противоречивых решений при и .
Для Paxos дальше важны , , и . Для Raft —, и .
Практическая цена этого контура проявляется через , , , , , и модель , которую реплики должны выполнять в одинаковом порядке.
Консенсус нужен тогда, когда несколько узлов должны принять одно и то же решение о состоянии системы, даже если часть сообщений задерживается, часть узлов падает, а сеть временно распадается на сегменты. Без него нельзя надёжно выбрать лидера, зафиксировать порядок записей или поддерживать единую историю критичных изменений.
Фундамент
Протокол TCP
Консенсус строится поверх обмена сообщениями, но корректность даёт не транспорт, а кворумы, номера раундов и правила фиксации.
Где консенсус действительно нужен
Выбор лидера
Координатор в кластере должен быть ровно один: два активных лидера одновременно — это два расходящихся источника правды и потерянные записи.
Метаданные кластера
Состав участников, конфигурации, схема данных и правила маршрутизации меняются редко, но менять их вразнобой нельзя — порядок изменений должен быть единым для всех узлов.
Линеаризуемая запись
Там, где важен строгий порядок, критичные операции должны выглядеть так, будто прошли через одну последовательную историю, а не через несколько параллельных.
Проверка на практике
Jepsen и модели консистентности
Jepsen-тесты не раз находили кластеры, где кворумы фактически переставали пересекаться — и системы спокойно фиксировали противоречивые истории.
Кворумная арифметика: почему 2f + 1
Все протоколы этой главы опираются на одно и то же рассуждение. Пусть в кластере N узлов, и решение считается принятым, когда его подтвердил из Q узлов. Два требования зажимают Q с двух сторон.
Живучесть: Q ≤ N − f
Кворум должен собираться даже после отказа f узлов. Если для решения нужно больше, чем N − f подтверждений, один лишний сбой остановит запись навсегда — живые узлы будут вечно ждать мёртвых.
Безопасность: 2Q > N
Любые два кворума обязаны пересекаться хотя бы в одном узле. Иначе при две непересекающиеся группы зафиксируют разные решения — это и есть .
Складываем оба требования: N − f ≥ Q > N/2, откуда N > 2f. Минимальный кластер, переживающий f отказов, — это N = 2f + 1 узлов с кворумом Q = f + 1. Узел из пересечения двух кворумов работает «свидетелем»: любой будущий кворум обязательно содержит того, кто видел уже принятое решение, поэтому новый лидер физически не может зафиксированное «не заметить». На этом пересечении держится вся безопасность Paxos, Raft и ZAB.
| Узлов (N) | Кворум | Терпит отказов (f) | Комментарий |
|---|---|---|---|
| 2 | 2 | 0 | Хуже одного узла: добавили точку отказа, не добавив устойчивости |
| 3 | 2 | 1 | Минимальный отказоустойчивый кластер — стандарт для etcd и Consul |
| 4 | 3 | 1 | Та же устойчивость, что у трёх узлов, но кворум больше и медленнее |
| 5 | 3 | 2 | Переживает отказ узла даже во время обслуживания другого |
| 7 | 4 | 3 | Практический потолок: каждая запись ждёт уже четыре подтверждения |
Почему чётный размер — пустая трата
Четыре узла терпят столько же отказов, сколько три (f = 1), но большинство выросло с двух до трёх: каждая запись ждёт лишнее подтверждение, а машин, способных сломаться, стало больше. Чётный кластер платит за надёжность, которой не получает, поэтому ZooKeeper и etcd рекомендуют 3 или 5 узлов: три — когда хватает одного запасного отказа, пять — когда кластер должен пережить аварию во время планового обслуживания.
Читающие и пишущие кворумы: R + W > N
Пересечение обобщается: если запись подтверждают W узлов, а чтение опрашивает R, то при R + W > N читающий кворум гарантированно заденет хотя бы одну свежую копию. Raft и Paxos используют симметричный случай W = R = f + 1, а -хранилища вроде Cassandra позволяют двигать R и W по обстоятельствам.
Важно: кворумные чтения и записи сами по себе — ещё не консенсус. Без номеров раундов и правила фиксации пересечение гарантирует видимость свежей копии, но не единую историю операций.
Safety и liveness: два сорта гарантий
Свойства распределённого алгоритма принято делить на два класса, и для консенсуса это деление — не формальность, а главный проектный выбор: от какого класса гарантий протокол готов отказаться, когда сеть ведёт себя плохо.
Safety: «плохое не случится никогда»
Нарушение safety видно на конечном отрезке исполнения и непоправимо задним числом. Для консенсуса это три свойства:
- Agreement — никакие два корректных узла не примут разные значения для одного слота журнала.
- Validity — принятое значение действительно кто-то предлагал, протокол его не выдумал.
- Integrity — узел принимает решение не более одного раза и не меняет его.
Liveness: «хорошее в итоге произойдёт»
Нарушение liveness нельзя предъявить никаким конечным отрезком — всегда можно возразить «ещё чуть-чуть, и решили бы». Для консенсуса это:
- Termination — каждый корректный узел в конце концов принимает решение.
- Практически: выборы завершаются, записи фиксируются, кластер не зависает в бесконечных перевыборах.
Что Raft и Paxos обещают всегда, а что — «по погоде»
Safety у обоих безусловна: при любых задержках, потерях, дубликатах и переупорядочении сообщений зафиксированная запись не откатится, а два лидера в одном не появятся. Границы этой честности: не более f отказов типа «остановка», нет византийских узлов, диск не теряет данные после . Liveness — условна: она держится на том, что сеть достаточно долго ведёт себя прилично. Авторы Raft формулируют это как требование к времени: broadcastTime ≪ electionTimeout ≪ MTBF — раунд доставки с подтверждением занимает 0,5–20 мс, тайм-аут выборов выбирают в диапазоне 10–500 мс, а отказы узлов случаются раз в недели и месяцы. Пока неравенство выполняется, кластер стабильно держит лидера; когда сеть его ломает, кластер перестаёт принимать записи — но не начинает противоречить сам себе.
Статья
FLP, JACM 1985
Оригинальная статья Фишера, Линч и Патерсона о невозможности детерминированного консенсуса в асинхронной системе.
FLP: почему консенсус нельзя гарантировать
В 1985 году Майкл Фишер, Нэнси Линч и Майкл Патерсон доказали результат, который очертил границы всей области и позже был отмечен премией Дейкстры: в полностью — без верхней границы задержек сообщений и без синхронизированных часов — ни один детерминированный протокол консенсуса не может гарантировать завершение, если хотя бы один процесс может молча остановиться.
"Every protocol for this problem has the possibility of nontermination, even with only one faulty process."
Что именно доказано
Под удар попадает только liveness. Для любого детерминированного протокола существует «неудачное» расписание доставки сообщений, при котором система вечно остаётся в нерешённом состоянии. Safety при этом достижима — невозможной оказывается именно гарантия завершения.
Почему так
В асинхронной модели нельзя отличить отказавший узел от очень медленного. Ждать его — можно ждать вечно; решить без него — он может «ожить» и проголосовать иначе. Доказательство показывает, что противник, управляющий доставкой сообщений, всегда удержит протокол в состоянии, где исход ещё не предрешён.
Чего теорема не утверждает
FLP не говорит, что консенсус «не работает на практике», — она запрещает гарантию в худшем случае. Реальные сети асинхронны лишь временами, и инженерный вопрос звучит иначе: как сделать плохие периоды редкими, а поведение в них — безопасным.
Как практические системы обходят FLP
1. Тайм-ауты = частичная синхронность
Дворк, Линч и Стокмайер (1988) формализовали модель : после неизвестного заранее момента стабилизации сеть начинает доставлять сообщения за ограниченное время. В этой модели консенсус решаем — и именно в ней живут Raft и Paxos: safety при любом поведении сети, liveness после стабилизации. Каждый в Raft — это ставка на то, что стабильный период уже наступил.
2. Рандомизация
Бен-Ор (1983) показал, что случайность обходит детерминированный запрет: протокол с подбрасыванием монетки завершается с вероятностью 1. Прямое инженерное эхо этой идеи — рандомизированные тайм-ауты выборов в Raft: случайный разброс разрывает симметрию, при которой кандидаты бесконечно делят голоса поровну.
3. Выбор лидера как детектор отказов
Теоретики выделили минимальную добавку к асинхронной модели, при которой консенсус становится решаемым: механизм, который «в конце концов» указывает всем на одного живого лидера (детектор отказов Ω Чандры и Туэга). в Raft, Multi-Paxos и ZAB — инженерная реализация этой абстракции. Поэтому liveness выборов условна по той же причине: при нестабильной сети перевыборы могут идти бесконечно, но протокол никогда не допустит двух лидеров с одним номером срока.
Как Paxos выбирает одно значение
Задача Paxos — выбрать одно значение, когда несколько узлов предлагают своё, а часть из них может отказать прямо посреди голосования. Алгоритм Лэмпорта решает её в два хода: на фазе подготовки участники обещают не принимать более старые предложения, на фазе принятия кворум фиксирует выбранное значение. Эти обещания и есть то, что не даёт двум конкурирующим предлагающим узлам зафиксировать разные значения.
Paxos: обмен сообщениями между узлами
Сценарии показывают, как кворум выбирает одно значение и что происходит при конкурирующих предложениях.
Одно значение
Paxos выбирает значение через кворум
Предлагающий узел проходит две фазы: сначала собирает обещания, затем отправляет значение на принятие.
Активный шаг
Prepare(n) уходит в кворум
Предлагающий узел выбирает номер раунда и отправляет Prepare(n) принимающим узлам.
Схема взаимодействия узлов
Что защищает
Кворумы фаз пересекаются, поэтому два разных значения не могут быть безопасно выбраны одновременно.
Где основной риск
Без стабильного лидера конкурирующие предлагающие узлы могут тратить много сетевых раундов.
На что смотреть
Номера предложений, размер кворума и то, какое значение возвращается в Promise.
Что важно при реализации
- •Prepare и Accept можно считать двумя сетевыми барьерами безопасности.
- •Promise обязан вернуть последнее принятое значение, иначе нарушается безопасность.
- •Learner не выбирает значение сам: он только узнаёт результат кворума.
Multi-Paxos: как уменьшается число раундов
Если лидер стабилен, подготовительную фазу не нужно повторять для каждой записи. Лидер один раз закрепляет номер предложения, а затем отправляет новые значения сразу в раунд принятия.
Что это даёт
- Меньше сетевых раундов на запись
- Выше пропускная способность при стабильном лидере
- Проще поддерживать прогресс, когда несколько клиентов конкурируют за запись
Multi-Paxos: поток сообщений
Сценарии показывают короткий путь записи при стабильном лидере и безопасную смену лидера.
Стабильная запись
Multi-Paxos сокращает путь записи при стабильном лидере
Лидер уже прошёл подготовительную фазу, поэтому каждая новая запись идёт сразу через раунд принятия.
Активный шаг
Лидер удерживает номер предложения
Подготовительная фаза уже выполнена, и кворум признаёт лидера владельцем текущего номера.
Схема взаимодействия узлов
Что защищает
Безопасность Paxos сохраняется, но обычная запись обходится без повторного Prepare.
Где основной риск
Если лидер завис или потерял связь с большинством, стабильный путь перестаёт давать прогресс.
На что смотреть
Стабильность лидера, задержку записи и долю записей, которые требуют нового Prepare.
Что важно при реализации
- •Multi-Paxos не меняет правила безопасности Paxos, а оптимизирует повторяющиеся записи.
- •Клиентский путь становится короче, пока лидер не конкурирует с другим предлагающим узлом.
- •Для чтений всё равно нужны правила, которые не обходят актуальный кворум.
Как Raft делает консенсус понятнее
Понятность здесь — не украшение, а проектная цель: Paxos слишком легко реализовать с ошибкой. Raft жёстко разделяет три механизма — выбор лидера, репликацию журнала команд и изменение состава кластера, — и за счёт этого его поведение проще объяснить команде, реализовать без скрытых дефектов и отладить, когда кластер ведёт себя не так.
Raft: взаимодействие узлов
Сценарии показывают выбор лидера, фиксацию записи и отказ устаревшего лидера от роли.
Выбор и фиксация
Raft выбирает лидера и фиксирует запись через большинство
Сначала кандидат получает голоса большинства, затем лидер реплицирует команду и продвигает индекс фиксации.
Активный шаг
Срабатывает тайм-аут выборов
Реплика не видит сигналов лидера, увеличивает срок полномочий и становится кандидатом.
Схема взаимодействия узлов
Что защищает
Лидер появляется только после большинства голосов, а запись фиксируется только после большинства подтверждений.
Где основной риск
Неверные тайм-ауты вызывают лишние выборы и задерживают фиксацию записей.
На что смотреть
Срок полномочий, большинство голосов, lag реплик и движение commit index.
Что важно при реализации
- •Raft отделяет выбор лидера от репликации журнала, чтобы поведение было проще проверять.
- •Команда клиента безопасна только после подтверждения большинством, а не после записи у одного лидера.
- •Реплики применяют записи к конечному автомату в порядке журнала.
Paxos и Raft: инженерное сравнение
Paxos
- Сильная теоретическая база и компактная формальная модель
- Сложнее объяснить и реализовать без ошибок
- В продуктах часто прячется за Multi-Paxos или производными алгоритмами
Raft
- Явная модель лидера, сроков полномочий и репликации журнала
- Проще объяснять команде и сопровождать в эксплуатации
- Используется в etcd, Consul, CockroachDB и других системах
Диссертация
Consensus: Bridging Theory and Practice
Диссертация Онгаро о Raft: одношаговые изменения состава, оптимизации чтения и уроки реализации.
Raft, Multi-Paxos и ZAB: три школы лидерского консенсуса
В эксплуатации сегодня доминируют три семейства: Raft, Multi-Paxos и ZAB (протокол атомарного вещания ZooKeeper). Все три держат через кворумы большинства, но по-разному отвечают на три инженерных вопроса: насколько силён лидер, как кластер восстанавливается после его смены и как безопасно менять состав участников.
| Аспект | Raft | Multi-Paxos | ZAB |
|---|---|---|---|
| Роль лидера | Сильный лидер: все записи идут через него, журнал течёт только от лидера к остальным | Оптимизация: протокол корректен и при нескольких конкурирующих предлагающих узлах — страдает только скорость | Primary-backup: основной узел порождает упорядоченные изменения состояния; эпоха играет роль срока полномочий |
| Выборы и восстановление | Голос отдаётся только кандидату с не менее полным журналом, поэтому новый лидер уже содержит всё зафиксированное | Лидером может стать узел с пробелами в журнале: prepare-фаза дочитывает незакрытые слоты у кворума | Фазы обнаружения и синхронизации: лидер собирает самую полную историю и выравнивает кворум до начала вещания |
| Изменение состава | Объединённый консенсус (joint consensus) с двойным кворумом двух конфигураций или одношаговые изменения из диссертации | Конфигурация — обычная запись журнала, вступающая в силу через α слотов | До ZooKeeper 3.5.0 — перезапуски с новым конфигом; начиная с 3.5.0 — динамический reconfig без остановки |
| Где используется | etcd (а через него платформа Kubernetes), Consul, CockroachDB, TiKV, Kafka KRaft | Chubby, Spanner и другие внутренние системы Google | ZooKeeper — а поверх него HBase, Hadoop и Kafka до версии 4.0 |
Объединённый консенсус (joint consensus): зачем две конфигурации
Переключить кластер со старого состава на новый одним шагом нельзя: в момент перехода большинство старой и большинство новой конфигураций могут не пересекаться и выбрать двух лидеров. Поэтому Raft из статьи 2014 года проводит кластер через переходную конфигурацию C(old,new), где каждое решение требует большинства в обеих группах одновременно.
Одношаговые изменения: проще, но с историей
Диссертация Онгаро предлагает менять состав по одному узлу за раз: кворумы соседних конфигураций пересекаются автоматически, и двойной кворум не нужен. Позже сообщество нашло в схеме тонкий дефект безопасности, и правило уточнили: лидер обязан сначала зафиксировать запись своего текущего срока и только потом применять изменение состава. Библиотека etcd-raft в итоге поддерживает обе схемы.
Фундамент
Синхронизация часов
Аренда на запись (lease) делает чтения корректными ровно настолько, насколько ограничен дрейф часов: это прямая зависимость от материала главы о времени.
Практические следствия: цена в сетевых раундах и граница применения
Сколько стоит одна запись
- При стабильном лидере: запрос клиента к лидеру, затем один кворумный на репликацию плюс журнала на кворуме узлов — диск входит в критический путь каждой записи.
- Базовый Paxos без закреплённого лидера тратит два кворумных раунда (prepare + accept) на каждое значение — именно поэтому все практические системы закрепляют лидера.
- Смена лидера — пауза записи на тайм-аут выборов и сами выборы; в геораспределённом кластере каждый кворумный раунд добавляет десятки миллисекунд межрегиональной задержки.
Три способа читать из консенсус-кластера
Чтение с лидера «как есть»
Лидер отвечает из своего состояния без дополнительных проверок.
Цена: 0 внутри кластера.
Лидер может быть уже смещён и не знать об этом: устаревший лидер отдаст старые данные и нарушит линеаризуемость. Допустимо только там, где немного устаревшее чтение не страшно.
Read index
Лидер запоминает индекс фиксации, подтверждает своё лидерство кворумным раундом , дожидается применения журнала до этого индекса и отвечает.
Цена: 1 кворумный , но без записи на диск.
Линеаризуемо и заметно дешевле записи, однако каждое чтение всё ещё трогает кворум. Так по умолчанию работают линеаризуемые чтения в etcd.
Lease read
Пока действует аренда, возобновляемая -ами, лидер отвечает локально, не спрашивая кворум.
Цена: 0 на чтение.
Корректность держится на ограниченном дрейфе часов: уплывшие часы превращаются в устаревшие чтения. Так работают TiKV и Spanner — последний страхует аренды аппаратным TrueTime.
Почему «консенсус на каждую запись» не масштабируется
Лидер — один узел: его процессор, диск и сеть задают потолок пропускной способности всей группы, а каждая запись несёт кворумный и . Журнал внутри одной группы не шардируется, поэтому рост нагрузки упирается в самого лидера. Зрелые архитектуры проводят границу тремя способами:
- Консенсус только для метаданных. Chubby хранит конфигурацию и выборы мастеров для GFS и Bigtable, ZooKeeper — для HBase и Kafka до 4.0, etcd — для . Сами данные идут мимо консенсуса.
- Много маленьких групп. Spanner держит Paxos-группу на каждый таблет, CockroachDB и TiKV — Raft-группу на каждый диапазон ключей: масштаб достигается шардированием групп, а не ростом одной.
- Разные гарантии для разных данных. В Kafka с KRaft метаданные кластера проходят через Raft, а сами сообщения реплицируются более дешёвым механизмом .
Что важно запомнить
- Консенсус нужен не для каждой записи, а только там, где системе требуется одно согласованное решение.
- Кластер из 2f + 1 узлов терпит f отказов, потому что кворумы большинства гарантированно пересекаются; 3 и 5 узлов — стандарт, чётный размер не добавляет устойчивости.
- Safety протоколы гарантируют при любом поведении сети, liveness — только в достаточно стабильные периоды: FLP запрещает требовать большего от детерминированного алгоритма.
- Paxos показывает фундаментальную механику выбора значения, а Raft делает похожую идею удобнее для реализации.
- Цена консенсуса — кворум, дополнительные сетевые раунды, задержка записи и сложное восстановление после отказов.
Когда консенсус может навредить
Консенсус повышает корректность критичного состояния, но делает путь записи медленнее и сложнее. Если домен допускает временное расхождение, асинхронную репликацию или идемпотентное восстановление, более простой механизм часто будет надёжнее в эксплуатации.
Источники и материалы
Связанные главы
- Зачем нужны распределённые системы и консистентность - Карта раздела с базовыми моделями отказов, координации и границами консистентности.
- Теорема CAP - Объясняет, почему при сетевом разделении протоколу приходится выбирать, что защищать в первую очередь.
- Теорема PACELC - Цену согласования платят не только при авариях: теорема PACELC показывает, что в штатном режиме за консистентность тоже приходится отдавать задержку.
- Синхронизация часов в распределённых системах - Помогает понять, как рассинхронизация, дрейф часов и тайм-ауты влияют на устойчивость лидерских протоколов.
- Выбор лидера: паттерны и реализации - Практика переключения на резерв, аренд на запись и защиты от расщепления кластера поверх Raft и других механизмов координации.
- Распределённые транзакции: двухфазная и трёхфазная фиксация - Объясняет, чем координация межсервисных операций отличается от согласования реплицированного состояния.
- Jepsen и модели консистентности - Показывает, как проверять обещания консистентности и находить нарушения в реальных кластерах.
- Designing Data-Intensive Applications: приложения, интенсивно работающие с данными (краткий обзор) - Ключевой источник по репликации, журналам команд, консенсусу и компромиссам распределённых систем.
- Distributed Systems, 4th Edition: распределённые системы (краткий обзор) - Классическая теоретическая база по распределённым алгоритмам и моделям отказов.
- Лэсли Лэмпорт: причинность, Paxos и инженерное мышление - Исторический и практический контекст идей, из которых выросло семейство Paxos.