AP и CP: попытка «договориться» с CAP-теоремой

https://www.youtube-nocookie.com/embed/_PRL7gYCQ5Y

Автор: Сергей Петренко · HighLoad++ 2022

---

Когда часть кластера теряет связь с большинством, перед инженерами встаёт неприятный выбор. Можно запретить записи и сохранить единую историю. А можно снизить кворум, вернуть сервису доступность и принять риск расхождения данных.

В докладе Сергея Петренко команда Tarantool пробует сочетать оба режима: использовать Raft и синхронную репликацию, но сохранять возможность вручную ослабить ограничения во время аварии. CAP-теорему такая настройка не отменяет. Она лишь переносит последствия решения на тот момент, когда связь восстановится и две части кластера попытаются снова работать вместе.

Кому смотреть: инженерам, которые проектируют failover, настраивают кворумы или составляют инструкции на случай потери связи между ЦОДами.

Из этого можно взять в работу: дополнить процедуру аварийного снижения кворума планом последующего восстановления — как обнаружить расхождение, сохранить обе ветви и выбрать правильную историю.

---

В начале доклада Петренко уточняет определения. Consistency в CAP означает linearizability, а availability — обязанность каждого исправного узла ответить за конечное время. Противоречие возникает во время сетевого разделения: система не может одновременно разрешить обеим сторонам продолжать работу и гарантировать единый порядок операций.

Даже наличие Raft не делает любую конфигурацию автоматически CP. Если выборы лидера соседствуют с асинхронной репликацией, изолированный старый лидер некоторое время может продолжать принимать записи. В другой части кластера большинство тем временем выберет нового лидера. После восстановления связи у системы окажутся две истории с операциями, которые уже были подтверждены клиентам.

В одном из инцидентов Tarantool две ноды независимо работали около полутора минут. На ручное восстановление порядка журналов ушло примерно девять часов. Это не универсальное соотношение, а конкретный случай, который показывает разницу между временем возникновения split brain и стоимостью его устранения.

Check quorum сокращает опасный промежуток, но не убирает его полностью: старый лидер обнаруживает потерю большинства только после таймаута. Синхронная репликация тоже не спасёт, если операторы вручную снизят кворум в обеих половинах разделённого кластера. Каждый лидер получит право подтверждать собственные записи.

В показанном решении Tarantool записи promote фиксируют историю смены лидеров. Если узлы видят несовместимые ветви, репликация останавливается до их автоматического смешивания. Данные остаются доступны для разбора, но выбрать правильную историю должен человек.

Поправка на 2026 год: доклад описывает Tarantool 2022 года. В современных версиях появились более развитые механизмы failover и сценарии синхронной репликации для нескольких ЦОДов. Фундаментальное ограничение осталось прежним: снижение кворума возвращает возможность записи, но не гарантирует автоматического слияния независимо подтверждённых историй.