Кворум задаёт достаточное участие в решении. Raft дополнительно задаёт выбор лидера, допустимость журнала и его фиксацию. Правила голосов конкретного кластера, включая свидетелей, нельзя переносить в Raft по одному слову «кворум».
Практический смысл
Почему это важно
При выборе числа и размещения узлов нужно посчитать голосующий состав для нужного отказа, затем проверить сохранение лидера и продвижение журнала. Три машины в двух стойках могут оставить только один голос после потери стойки. Само наличие копий не даёт права независимо подтверждать новые решения.
Доказательная часть
Что подтверждено
Raft разделяет выбор лидера, репликацию журнала и обеспечение безопасности. Если один узел применил команду по некоторому индексу, другой не должен применить иную команду по тому же индексу. Это ограничение защищает общий порядок исполнения.
Граница применимости: Raft, свойство безопасности машины состояний при выполнении модели протокола.
Для фиксации новых записей Raft нужно взаимодействующее большинство участников с правом голоса. Это необходимое условие: само число живых процессов не доказывает прогресс. Нужны работоспособный лидер, допустимое состояние журнала, обмен сообщениями и выполнение предпосылок протокола по времени работы.
Граница применимости: Raft с фиксированным голосующим составом и отказами без злонамеренного поведения; произвольные задержки могут мешать продвижению даже при живых узлах.
Одинаковая последовательность команд позволяет копиям детерминированной машины состояний получать одинаковые результаты, если они начинают с одинакового состояния. Одного порядка недостаточно, если применение команд самопроизвольно даёт разные результаты на разных узлах.
Граница применимости: Модель репликации детерминированной машины состояний, не любые процессы с внешними побочными эффектами.
При неизменном составе из трёх голосующих участников Raft большинство равно двум, из пяти — трём. По одному только числу голосов потеря соответственно одного или двух участников оставляет большинство. Неголосующие копии не входят в этот расчёт, а оставшееся большинство ещё нужно связать и обеспечить работой протокола.
Граница применимости: Арифметика простого большинства фиксированного голосующего состава Raft; переход между составами и дополнительные ограничения реализации исключены.
Базовый Raft рассчитан на отказы и восстановление узлов, задержки, потери и перестановки сообщений без злонамеренного нарушения протокола участниками. Число допустимых отказов этой модели нельзя выдавать за защиту от узлов, подделывающих сообщения или произвольно меняющих историю.
Граница применимости: Модель отказов исходного Raft; византийская устойчивость отдельно не заявляется.
Если два из трёх голосующих участников находятся на одной площадке, её потеря оставляет один голос из трёх. Большинство исчезает, хотя один сервер исправен. Перенос неголосующей копии на третью площадку не меняет этот подсчёт.
Граница применимости: Учебный пример фиксированного голосующего состава Raft и полного отказа площадки; независимые причины потери голосов отдельно не рассматриваются.
При смене состава через совместную конфигурацию Raft требует отдельного большинства прежнего и нового состава. Нельзя сложить все известные узлы и заменить эти два условия одним большинством от общей суммы.
Граница применимости: Алгоритм совместного согласования конфигураций в исходной статье Raft; иные реализации смены состава требуют собственной проверки.
Граница терминов
Не путать
Репликация создаёт копии данных. Консенсус Raft согласует допустимый порядок и правила принятия новых записей. Само наличие нескольких копий ещё не доказывает, что они могут независимо подтверждать совместимые решения.
Перед спецификацией
Что проверить
- Назовите протокол, модель отказов и фактический голосующий состав.
- Считайте неголосующие копии отдельно от участников большинства.
- Разместите голоса на схеме стоек и площадок; пересчитайте их после каждого требуемого отказа.
- Проверьте связность оставшегося большинства, выбор лидера и фактическую фиксацию новой команды.
- При разделении убедитесь, что меньшинство не подтверждает новые зафиксированные записи самостоятельно.
- Для смены состава проверьте правило перехода, а не только итоговое число узлов.
- Не переносите расчёт отказов обычного Raft на злонамеренных участников или повреждение сохранённого состояния.
Открытые основания
Первоисточники
In Search of an Understandable Consensus Algorithm (Extended Version)
Stanford University / USENIX · Ongaro and Ousterhout, USENIX ATC 2014 extended paper
Первичное описание Raft: leader election, replicated log, commit majority и safety.
Открыть первоисточникTime, Clocks, and the Ordering of Events in a Distributed System
Microsoft Research / ACM · Leslie Lamport, CACM 21(7), July 1978
Определяет happens-before, logical clocks и связь total ordering со replicated state machine.
Открыть первоисточникFailover Clustering in Windows Server and Azure Local
Microsoft · Microsoft Learn, обновлено 25 июня 2025 года
Описывает nodes, clustered roles, health monitoring, failover и quorum в failover cluster.
Открыть первоисточникPostgreSQL 18 Documentation: Log-Shipping Standby Servers
PostgreSQL Global Development Group · PostgreSQL 18, Chapter 26.2
Фиксирует async default, synchronous commit wait points и связь replication delay с data loss.
Открыть первоисточник