Кратко: при сетевых сбоях система вынуждена выбирать между согласованностью и доступностью (CAP). Конкретные подходы — репликация с настраиваемой согласованностью (quorum), и использование консенсусных протоколов (Paxos/Raft) — дают разные компромиссы. Ниже — суть, формулы и практические рекомендации.
CAP
- Теорема: в присутствии разделения сети (P) нельзя одновременно гарантировать как строгую согласованность (C), так и доступность (A) для всех операций. При partition вы обязаны выбрать C или A для пострадавшего множества узлов.
- Практический вывод: система должна явно определить поведение при разделе (предпочесть C — отказ в обслуживании части запросов, или A — возвращать возможно устаревшие данные).
Репликация: типы и настройки
- Мастер-слейв (single leader): сильная согласованность для записей через лидера, простота; при недоступности лидера — либо отказ (CP), либо сложная фейловер-логика.
- Мульти-мастер (multi-leader) / асинхронная репликация: высокая доступность (AP), возможны конфликты и требуются разрешения/комбинации (CRDT / application-level merge).
- Кворумная репликация (tunable consistency): параметризуемо числами $N$ (реплик), $W$ (запись), $R$ (чтение). Гарантия согласованности при выполнении:
$$R+W>N.$$ При этом повышая $W$ и $R$ вы усиливаете C, снижая A и увеличивая латентность.
Paxos / Raft (консенсусные протоколы)
- Обеспечивают строгую последовательную (обычно линейную) согласованность и устойчивую к сбоям репликацию лога при условии большинства здоровых узлов.
- Для прогресса требуется большинство: кворум = $\lfloor \frac{N}{2}\rfloor +1$. Если сеть разорвана так, что ни одна сторона не содержит большинства, запись невозможна (CP поведение).
- Raft обычно проще в реализации и отладки; Paxos — более абстрактен, но теоретически эквивалентен по свойствам безопасности.
- При partition: консенсус обеспечивает safety (никогда не возвращает противоречивые результаты), но жертвует liveness на изолированной стороне (нет обслуживания).
Практические подходы и паттерны
- Выбрать модель по требованиям: критичные данные → CP (Raft/Paxos, лидер, кворумы). Некачественные данные/кеши → AP (eventual, CRDT).
- Гибрид: метаданные / координаторы — через консенсус (CP); объёмные/нестрогие данные — через асинхронную репликацию или CRDT (AP).
- Tunable consistency: предоставить клиенту выбор $N,R,W$ (как в Cassandra) — пользователь сам решает компромисс.
- Линейные чтения без контакта с лидером: использовать чит-лейс (lease) или подтверждённый кворум; иначе чтения из локальной реплики рискнут быть старыми.
- Обработка разделений: детектировать partition, переключать режимы (read-only, degrade), избегать split-brain через жёсткую проверку кворума и автоматический фейловер.
- Улучшения доступности при консенсусе: географическое распределение с локальными мастер-копиями + глобальный консенсус для критичных операций; компромисс — локальные операции быстрые, глобальные — медленнее/блокируются на кворум.
Рекомендации при возникшей проблеме (недоступность части реплик)
1. Определить требуемый уровень согласованности для разных типов операций (SLA).
2. Для сильной согласованности: использовать Raft/Paxos, обеспечить, чтобы клиенты писали/читали через кворум/лидера; допустить временную недоступность при разделе.
3. Для доступности: разрешить обслуживать локальные реплики (AP), использовать CRDT/конфликт-решение, применить асинхронную репликацию и механизм eventual convergence.
4. Комбинировать: критичные операции через консенсус (CP), остальные через кворум/асинхронно (AP).
5. Тестировать сценарии partition и автоматические фейловеры, эмитировать задержки, мониторить кворумы и метрики латентности/консистентности.
Коротко: CAP диктует выбор при разделе; кворумная репликация и настраиваемая согласованность дают гибкость; Paxos/Raft обеспечивают строгую безопасность (но требуют большинства и снижают доступность при partition). Выбор зависит от требований к данным: если нельзя допускать расхождений — CP (консенсус); если важнее всегда отвечать — AP с eventual/CRDT и сложной логикой слияния.