Коротко и по делу — определения, суть CAP и примеры архитектурных компромиссов.
Определения
- Согласованность (consistency): все клиенты видят одну и ту же версию данных (в смысле линейза­бельности/сильной согласованности).
- Доступность (availability): каждый корректный запрос получает ответ (необязательно самый свежий) — система не возвращает только ошибки из‑за загрузки/фейлов.
- Устойчивость к разделению сети (partition tolerance): система продолжает работать при произвольной потере пакетов/разрывах связи между узлами (нет предположения о надёжности сети).
CAP в двух строчках
- При реальных сетевых разделениях (partition) нельзя одновременно обеспечить и строгую согласованность, и полную доступность. Формально — в присутствии разделения приходится выбирать между C и A; то есть не более $2$ из $3$ свойств достижимы для данной рабочей ситуации.
Практические следствия и формулы кворумов
- В кворумных схемах для гарантии сильной согласованности при репликации используют правило $R+W>N$, где $N$ — число реплик, $W$ — число подтверждений записи, $R$ — число ответов чтения. Это иллюстрирует компромисс: большие $W$ и $R$ → сильнее C, но выше задержки/меньше A.
Архитектурные решения и примеры (компромиссы)
- CP (Consistency + Partition tolerance, жертвуют Availability при разделении): лидерные протоколы с консенсусом (Paxos/Raft). Поведение: при потере кворума система блокируется до восстановления кворума, чтобы не нарушить согласованность. Примеры: ZooKeeper, etcd, HBase (по дизайну) — подходят для конфигурационного сервиса, метаданных, финанс. транзакций.
- AP (Availability + Partition tolerance, жертвуют Consistency): лидерless или мульти‑мастерные системы с разрешением конфликтов и eventual consistency. Поведение: система отвечает во время разделения, но данные могут расходиться и требовать слияния/разрешения. Примеры: Dynamo, Cassandra, Riak; часто используют CRDT или разрешение конфликтов на чтении/записи.
- CA (Consistency + Availability, не терпит Partition): возможна только если гарантируется отсутствие сетевых разделений (фактически нераспределённая система или одноадресный мастер). Примеры: однопроцессные СУБД, или классические RDBMS в условиях сети без разделений. В реальных геораспределённых системах CA неприменима как постоянный режим.
- Гибридные/настраиваемые подходы:
- Тюнлабельная согласованность (Cassandra): клиент выбирает уровень согласованности на операцию (например, QUORUM vs ONE) — баланс C↔A динамически.
- Multi‑datacenter с синхронной локальной/асинхронной глобальной репликацией (локально CP, глобально AP) — пример: некоторые конфигурации MongoDB, архитектуры с горячими локальными кворумами и отложенной глобальной репликацией.
- Спецрешения для глобальной строгой согласованности: Google Spanner — использует синхронизацию времени (TrueTime) для получения глобальной согласованности с высокой доступностью; при сетевых разделениях всё ещё склоняется к CP (может блокировать операции).
- CRDT и операции без конфликтов — позволяют AP‑поведение с математической гарантий сходимости без централизованного разрешения конфликтов.
Практические рекомендации (когда что выбирать)
- Нужно строгие семантики (платёжные операции, контроль состояний) → выбирать CP‑ориентированный дизайн (консенсус, блокировки, большей латентностью).
- Нужна высокая доступность и малая задержка при возможных разделениях (социальные фиды, кеши, метрики) → AP‑ориентированный подход с eventual consistency, CRDT или разрешением конфликтов.
- Нужна гибкость — дать приложению выбирать уровень согласованности для каждой операции → tunable consistency (quorum параметры).
Кратко о издержках
- C ↔ задержка и риск недоступности при разделе; A ↔ возможность рассинхронизации и дополнительные механизмы слияния/разрешения конфликтов; P ↔ выбор между C или A в реальном времени.
Если нужно, могу привести конкретные схемы репликации/настройки кворумов для вашей задачи.