Кратко о CAP: в распределённой системе при наличии сетевого разделения (partition) нельзя одновременно гарантировать и строгую консистентность (C), и полную доступность (A). Система всегда должна быть устойчивой к разделениям (P) — значит в момент partition приходится выбирать: жертвуем доступностью или консистентностью.
Пример: распределённый чат, репликация сообщений на $N$ серверов.
1) Модель репликации через кворумы
- Параметры: чтение требует квoрума $R$, запись — $W$. Гарантия строгой консистентности при отсутствии partition достигается если
$$R+W>N.$$ - Компромисс: чтобы повысить доступность, можно поставить $W=1$ (писать на любой реплике), но тогда нужен большой $R$ для согласованного чтения; наоборот, для строгой C обычно берут $W=\lceil N/2\rceil$ (лидер/меньшинство), что увеличивает задержку и снижает доступность при partition.
2) CP-подход (консистентность в ущерб доступности)
- Реализация: leader-based (Raft/Paxos). Все сообщения проходят через лидера, который реплицирует синхронно на большинство ($W=\lceil N/2\rceil$).
- Поведение при partition: если клиент попал на сторону без лидера — операции записи/чтения блокируются или возвращают ошибку (снижение доступности).
- Плюсы: строгий порядок сообщений, отсутствие конфликтов, простая модерация/удаление.
- Минусы: пользователи на "отрезанной" стороне видят ошибку/недоступность, увеличенная задержка из-за синхронной репликации.
3) AP-подход (доступность в ущерб строгой консистентности)
- Реализация: локальные записи на любой реплике, асинхронная репликация, использование CRDT или логов с последующим слиянием (eventual consistency). Можно поддержать каузальную консистентность через векторные часы (вектор длины $N$).
- Поведение при partition: обе стороны принимают сообщения — система остаётся доступной. После восстановления реплик сообщения сливаются; возможны конфликты/аномалии порядка.
- Плюсы: высокая доступность и низкая задержка, пользователи продолжают писать в офлайне.
- Минусы: возможные дубли, пересортировка сообщений, сложная семантика удаления/модерации.
4) Гибриды и практические рецепты
- Сессионная привязка (sticky sessions): направлять клиента на один репликат для сохранения read-your-writes; при partition клиент остаётся доступен локально, но видит ограничённый набор данных — компромисс между A и C.
- Разделение операций: критичные операции (удаление сообщения, бан) через CP-сервис; обычные сообщения — AP/CRDT. Это даёт доступность для чата и консистентность для правил/модерации.
- Использовать каузальную/сессинную согласованность вместо глобальной строгой: уменьшает видимые конфликты, остаётся доступным при partition.
5) Конкретный сценарий (иллюстрация)
- Допустим $N=3$ реплики. В CP-режиме запись требует $W=\lceil 3/2\rceil =2$. При разделении 2/1 сторона с одной репликой не сможет писать — снижена доступность. В AP-режиме можно писать на обе стороны ($W=1$), но после объединения придётся разрешать порядок/дубликаты.
Вывод: для чата часто практичнее отдать приоритет доступности и устойчивости к разделениям (AP) с каузальной/временной согласованностью и CRDT/слиянием, дополняя строгие CP-операции там, где требуется абсолютная согласованность (модерация, платёжные транзакции). Выбор зависит от требований к порядку сообщений, задержке и от того, готовы ли вы решать конфликты после partition.