CAP и PACELC

CAP, сформулированная точно

Теорема CAP (Брюер; доказана Гилбертом и Линчем) — о трёх свойствах распределённого хранилища. Прежде чем правильно использовать эти метки на ревью дизайна, нужно знать, что именно означает каждая — и что она не означает:

• Консистентность (C) — каждое чтение видит самую свежую запись (конкретно — линеаризуемость: система ведёт себя так, будто копия данных одна и операции идут в едином порядке). Заметь: это не C из ACID — буква та же, идея другая.
• Доступность (A) — каждый запрос к неупавшему узлу получает не-ошибочный ответ (пусть и не свежайшие данные).
• Терпимость к партиции (P) — система продолжает работать, когда сеть роняет или задерживает сообщения между узлами.

Реальное содержание теоремы узко и условно: когда случается сетевая партиция, надо выбрать между C и A — оба нельзя. Если два узла не могут общаться и запись легла на один, другой либо отказывается отвечать (жертвуя A ради консистентности → CP), либо отвечает своими возможно устаревшими данными (жертвуя C ради доступности → AP). Вот и всё. Доказательство почти тривиально, едва сформулировано так: партиционированный узел, всё же отвечающий, либо лжёт (не C), либо встаёт (не A).

Почему CAP так часто перевирают

Три мифа, все стоит разучить:

1. «Выбери два из трёх». Уронить P нельзя. В любой реальной распределённой системе сетевые партиции будут — это факт физики и эксплуатации, а не выбор дизайна (Amazon Builders’ Library прямо говорит, что независимые отказы и партиции неизбежны). Так что P обязателен, и живой выбор — лишь C-против-A пока идёт партиция. «Выбери два» звучит так, будто CA — опция; для распределённого хранилища это не так.
2. «Моя база AP/CP, точка». Выбор может быть на операцию, а не на систему. DynamoDB по умолчанию делает eventual-консистентные чтения (AP-подобно), но предлагает флаг ConsistentRead для строго консистентных чтений той же таблицы. Многие системы дают выбирать консистентность на запрос, так что навешивание одной буквы на всю базу прячет реальное настраиваемое решение.
3. CAP описывает всю систему. Она описывает поведение лишь во время партиции. Инженер из hook схлопнул «что мы делаем в кризис» в «что есть наша система» и упустил компромисс, реально присутствующий каждый день, — ровно то, что добавляет PACELC.

Все три мифа вытекают из одного корня: CAP воспринимают как широкую классификацию системы, а не как условное утверждение — только о моменте партиции. Когда увидишь метку «AP» или «CP» в дизайн-доке, твой следующий вопрос: «на операцию или на систему?» и «а что происходит, когда сеть здорова?»

PACELC: остальное время

PACELC (Абади) расширяет CAP на нормальную работу:

PAC | ELC
Если Partition  → выбери Availability или Consistency
Else (норма)    → выбери Latency      или Consistency

Читай как: если есть Partition, меняй A против C (это CAP); Else (иначе) меняй L против C. Ветвь «иначе» — это инсайт. При здоровой сети строго консистентное чтение всё равно должно координироваться через реплики (ждать кворум, говорить с лидером) — что стоит задержки. Чтобы быстрее, читаешь с близкой реплики, которая может слегка устареть, — что стоит консистентности. Так что даже при нуле партиций ты постоянно выбираешь, сколько задержки платить за сколько свежести. Этот компромисс присутствует на каждом запросе, поэтому формирует систему куда сильнее, чем редкая партиция.

Базы получают двусоставную метку: DynamoDB и Cassandra — PA/EL (доступны при партиции, низкая задержка, но устаревшее иначе); строго консистентное хранилище вроде однолидерной SQL-базы или Spanner склоняется к PC/EC (консистентно при партиции, консистентно, но выше задержка иначе). Метка наконец схватывает и кризисное, и повседневное поведение.

Спектр консистентности и выбор по кейсу

C-против-A и L-против-C не бинарны; это спектр моделей консистентности (Jepsen каталогизирует их как свойства безопасности — какие истории система вправе порождать). От сильнейших к слабейшим, несущие ступени:

• Линеаризуемая (строгая) — чтения всегда видят свежайшую запись; система ведёт себя как одна копия. Сильнейшая, дороже всех, наименее доступна при партиции.
• Последовательная / каузальная — операции уважают консистентный порядок (каузальная: следствия не появляются раньше причин — ты никогда не видишь ответ раньше сообщения, на которое он отвечает).
• Read-your-writes / монотонные чтения — гарантии на клиента (видишь свои записи; чтения не идут назад) без глобальной силы — починка-маршрутизация урока 01 живёт здесь.
• Eventual — реплики сходятся, если записи прекратятся, без обещаний порядка или свежести тем временем. Слабейшая, дешевейшая, доступнейшая.

Senior-ход — выбирать по кейсу, а не по компании:

• Баланс банка или декремент склада, который не должен перепродать → линеаризуемая / CP / EC: корректность важнее доступности и задержки.
• Счётчик лайков, лента, метка «последний раз в сети», счётчик просмотров страницы товара → eventual / AP / EL: пара секунд устаревания невидима пользователю и покупает огромную доступность и скорость.
• Пользователь, редактирующий собственный профиль → read-your-writes достаточно: он должен видеть своё изменение, но глобальная строгая консистентность избыточна.

Поэтому одна компания держит Postgres для заказов и Cassandra/DynamoDB для ленты активности: точку на спектре выбирают данные, а не догма.