Кратко о CAP
- Теорема CAP: невозможно одновременно в распределённой системе обеспечить все три свойства — согласованность (Consistency, C), доступность (Availability, A) и устойчивость к сетевым разделениям (Partition tolerance, P). Формально: $\neg (C\wedge A\wedge P)$. Практическое следствие: при возникновении сетевого разделения нужно жёстко выбирать между C и A (P считается обязательной в реальной сети).
Что означает каждое свойство
- Согласованность (C): каждая операция чтения возвращает «последнюю» запись (обычно интерпретируется как линейная согласованность / single-copy consistency).
- Доступность (A): каждый корректный запрос получает ответ (не важно — актуальный или устаревший).
- Устойчивость к разделениям (P): система продолжает работать при потере/задержке сообщений между узлами; разделения возникают неизбежно в сети.
Примеры систем и выборов
- Выбирают согласованность над доступностью (CP):
- Google Spanner — глобальная линейная согласованность, использует TrueTime и распределённый консенсус (Paxos); при разделениях часть кластера может стать недоступной.
- Apache HBase / HDFS (в связке с ZooKeeper) — консенсус/лидер-ориентированная репликация; при потере связи некоторые регионы становятся недоступны.
- ZooKeeper — системный сервис для согласованного хранения конфигурации/локов; предпочитает отказать при риске рассогласования.
- Выбирают доступность над согласованностью (AP):
- Amazon Dynamo, Cassandra, Riak — мульти-мастерная архитектура, асинхронная репликация, eventual consistency; система остаётся доступной при разделениях, но данные могут быть временно рассогласованы.
- CouchDB — репликация с разрешением конфликтов, ориентированность на оффлайн/многоузловую доступность.
- CA (Consistency + Availability) — возможна только при отсутствии сетевых разделений (непрактично для распределённых по сети). Примеры: однолинейные БД (single-node) или кластер с общим диском в контролируемой сети; в реальных WAN-сценариях CA недостижимо.
Как это отражается в дизайне распределённого хранилища
- Дизайн при выборе C (CP):
- Механизмы: лидеры, синхронная репликация, алгоритмы консенсуса (Paxos, Raft).
- Поведение: более высокая задержка записи/чтения, жёсткие блокировки/координация, при разделениях — отказоустойчивость через отказ сервисов (части кластера могут стать недоступны).
- Подходит для: банковских транзакций, систем учёта запасов, метаданных, где корректность важнее доступности.
- Дизайн при выборе A (AP):
- Механизмы: асинхронная репликация, мульти-мастер, anti-entropy, векторные часы/CRDT для разрешения конфликтов.
- Поведение: низкая задержка, высокая доступность при разделениях, возможны устаревшие данные и необходимость слияния конфликтов.
- Подходит для: пользовательских фидов, кэшей, систем с приоритетом отклика и терпимостью к временной рассогласованности.
- Тюнинг/компромиссы:
- Кворумы: настройка параметров чтения/записи. Правило для согласованности при кворуме: $(R+W>N)$, где $N$ — фактор репликации, $W$ — число реплик, подтверждающих запись, $R$ — число реплик, читающих данные.
- Tunable consistency (например, Cassandra, MongoDB): можно выбирать уровень согласованности на операцию — гибридные решения между C и A.
- Конфликт-менеджмент: AP-системы требуют политики разрешения конфликтов (автоматические CRDT или бизнес-логика).
Краткое практическое правило выбора
- Нужна строгая корректность данных → выбирайте CP (консенсус, синхронность).
- Нужна высокая доступность и низкая задержка при разделениях → выбирайте AP (асинхронность, eventual consistency).
- Если можно — используйте гибриды / настраиваемую согласованность и проектируйте уровни согласованности для разных типов данных.