CAP-теорема: консистентность, доступность и разделение

CAP-теорема утверждает, что распределённая система не может одновременно гарантировать Consistency, Availability и Partition tolerance

Почему это важно: понимание CAP объясняет поведение распределённых систем при сбоях и помогает принимать обоснованные архитектурные решения

Главная идея

сетевые разделения неизбежны; при разделении нужно выбрать: вернуть потенциально устаревшие данные (AP) или вернуть ошибку (CP)

Как это выглядит на практике

Сеть разделила кластер на два: node A и node B.
CP-система (HBase, ZooKeeper): node A отказывает отвечать пока не синхронизируется с B. Доступность нарушена.
AP-система (Cassandra, DynamoDB): node A отвечает со своими данными; они могут устареть. Консистентность нарушена.
После восстановления сети: AP-система сходится к консистентному состоянию (eventual consistency).
Банковский перевод: CP предпочтительнее (нельзя допустить двойное списание).

Что происходит под капотом

PACELC: расширение CAP; даже без разделения (E — Else) системы выбирают между Latency и Consistency.
Quorum reads/writes: требуем ответа от (N/2 + 1) узлов; баланс между CP и AP.
Vector clocks: отслеживают causality событий в распределённой системе для разрешения конфликтов.
Conflict-free Replicated Data Types (CRDTs): структуры данных, которые автоматически разрешают конфликты (счётчики, множества).
Linearizability: строжайшая форма консистентности; операции выглядят атомарными для всех наблюдателей.

Типичные ошибки и заблуждения

Ошибка: CAP означает выбор двух из трёх. Partition tolerance обязательна в распределённых системах; реальный выбор только CP vs AP при разделении.
Ошибка: eventual consistency — это слабая гарантия. При правильном дизайне eventual consistency покрывает большинство use cases; проблемы возникают только при конфликтах.
Ошибка: PostgreSQL — CA-система. PostgreSQL — CP при настройке репликации; при разделении ведомые узлы могут стать недоступными.
Ошибка: CAP — единственная важная теорема. PACELC более практична; CAP упрощает реальную картину.

Ключевые выводы

Partition tolerance обязательна; выбор между C и A при разделении.
CP: консистентность ценой доступности (банки, финансы).
AP: доступность ценой временной несогласованности (DNS, корзина в e-commerce).
Eventual consistency — не слабость, а компромисс с понятными гарантиями.

Термины урока

CAP-теорема: в распределённой системе при разделении нельзя гарантировать и C, и A.

Consistency (C): все узлы видят одни и те же данные в любой момент.

Availability (A): каждый запрос получает ответ (не ошибку).

Partition Tolerance (P): система работает при потере связи между узлами.

Eventual Consistency: все реплики в итоге сходятся к одному значению.

Quorum: минимальное число узлов, которые должны согласиться для операции.

Связь с работой backend-разработчика

Большинство backend-разработчиков работают с CA-подобными системами (PostgreSQL с репликацией). Понимание CAP нужно при проектировании распределённых сервисов, выборе между БД и объяснении поведения системы при сбоях.

Мини-разбор реальной ситуации

Cassandra в режиме eventual consistency: два пользователя одновременно обновляют имя в профиле на разных узлах. После синхронизации last-write-wins разрешает конфликт по timestamp. Для банковского счёта это неприемлемо; для имени пользователя — окей. CAP — это выбор, соответствующий бизнес-требованиям.

Что запомнить

P обязательна; выбор между C и A при разделении сети.
CP для финансов, AP для социальных фич и кэша.
Eventual consistency с пониманием конфликтов — это не 'плохая' консистентность.

Итог

CAP — фундаментальный компромисс распределённых систем. Понимание его помогает объяснить поведение БД при сбоях и принимать осознанные архитектурные решения вместо случайного выбора.