Кворум задаёт достаточное участие в решении. Raft дополнительно задаёт выбор лидера, допустимость журнала и его фиксацию. Правила голосов конкретного кластера, включая свидетелей, нельзя переносить в Raft по одному слову «кворум».
Распределённые данные
Распределённый консенсус
Определение
Распределённый консенсус — согласование несколькими узлами одного допустимого решения при заданной модели отказов. Для реплицируемого журнала такие решения задают общий порядок команд, а протокол Raft принимает новую запись только при взаимодействующем большинстве голосующих участников.
Также ищут: Distributed consensus · consensus algorithm
Зачем это знать
При выборе числа и размещения узлов нужно посчитать голосующий состав для нужного отказа, затем проверить сохранение лидера и продвижение журнала. Три машины в двух стойках могут оставить только один голос после потери стойки. Само наличие копий не даёт права независимо подтверждать новые решения.
Связи из словаря
Карта понятия
Распределённый консенсус
Доказательная часть
Что подтверждено
Raft разделяет выбор лидера, репликацию журнала и обеспечение безопасности. Если один узел применил команду по некоторому индексу, другой не должен применить иную команду по тому же индексу. Это ограничение защищает общий порядок исполнения.
Граница применимости: Raft, свойство безопасности машины состояний при выполнении модели протокола.
Для фиксации новых записей Raft нужно взаимодействующее большинство участников с правом голоса. Это необходимое условие: само число живых процессов не доказывает прогресс. Нужны работоспособный лидер, допустимое состояние журнала, обмен сообщениями и выполнение предпосылок протокола по времени работы.
Граница применимости: Raft с фиксированным голосующим составом и отказами без злонамеренного поведения; произвольные задержки могут мешать продвижению даже при живых узлах.
Одинаковая последовательность команд позволяет копиям детерминированной машины состояний получать одинаковые результаты, если они начинают с одинакового состояния. Одного порядка недостаточно, если применение команд самопроизвольно даёт разные результаты на разных узлах.
Граница применимости: Модель репликации детерминированной машины состояний, не любые процессы с внешними побочными эффектами.
При неизменном составе из трёх голосующих участников Raft большинство равно двум, из пяти — трём. По одному только числу голосов потеря соответственно одного или двух участников оставляет большинство. Неголосующие копии не входят в этот расчёт, а оставшееся большинство ещё нужно связать и обеспечить работой протокола.
Граница применимости: Арифметика простого большинства фиксированного голосующего состава Raft; переход между составами и дополнительные ограничения реализации исключены.
Базовый Raft рассчитан на отказы и восстановление узлов, задержки, потери и перестановки сообщений без злонамеренного нарушения протокола участниками. Число допустимых отказов этой модели нельзя выдавать за защиту от узлов, подделывающих сообщения или произвольно меняющих историю.
Граница применимости: Модель отказов исходного Raft; византийская устойчивость отдельно не заявляется.
Если два из трёх голосующих участников находятся на одной площадке, её потеря оставляет один голос из трёх. Большинство исчезает, хотя один сервер исправен. Перенос неголосующей копии на третью площадку не меняет этот подсчёт.
Граница применимости: Учебный пример фиксированного голосующего состава Raft и полного отказа площадки; независимые причины потери голосов отдельно не рассматриваются.
При смене состава через совместную конфигурацию Raft требует отдельного большинства прежнего и нового состава. Нельзя сложить все известные узлы и заменить эти два условия одним большинством от общей суммы.
Граница применимости: Алгоритм совместного согласования конфигураций в исходной статье Raft; иные реализации смены состава требуют собственной проверки.
Граница терминов
Не путать
Репликация создаёт копии данных. Консенсус Raft согласует допустимый порядок и правила принятия новых записей. Само наличие нескольких копий ещё не доказывает, что они могут независимо подтверждать совместимые решения.
Перед спецификацией
Что проверить
- Назовите протокол, модель отказов и фактический голосующий состав.
- Считайте неголосующие копии отдельно от участников большинства.
- Разместите голоса на схеме стоек и площадок; пересчитайте их после каждого требуемого отказа.
- Проверьте связность оставшегося большинства, выбор лидера и фактическую фиксацию новой команды.
- При разделении убедитесь, что меньшинство не подтверждает новые зафиксированные записи самостоятельно.
- Для смены состава проверьте правило перехода, а не только итоговое число узлов.
- Не переносите расчёт отказов обычного Raft на злонамеренных участников или повреждение сохранённого состояния.
Открытые основания
Первоисточники
- Time, Clocks, and the Ordering of Events in a Distributed System
Определяет happens-before, logical clocks и связь total ordering со replicated state machine.
Утверждения: 03
- Failover Clustering in Windows Server and Azure Local
Описывает nodes, clustered roles, health monitoring, failover и quorum в failover cluster.
- PostgreSQL 18 Documentation: Log-Shipping Standby Servers
Фиксирует async default, synchronous commit wait points и связь replication delay с data loss.