CAP-теорема и ее расширение PACELC или почему распределённые системы не могут быть идеальными¶
Представьте, что вы управляете банком. Клиент переводит деньги со счёта A на счёт B. В тот же момент происходит сбой в дата-центре: серверы в Москве теряют связь с серверами в Санкт-Петербурге. Что должна сделать ваша система?
- Вариант 1: заблокировать операцию, пока связь не восстановится, отдать клиенту ошибку, но данные оставить согласованными: деньги не исчезают и не дублируются.
- Вариант 2: принять операцию, но рискнуть, что один сервер зафиксирует списание, а другой не получит информацию о зачислении. Клиент увидит успешную операцию, но данные временно разойдутся, при восстановлении связи - синхронизируются.
Этот выбор не прихоть, а фундаментальное ограничение, описанное в CAP-теореме (Consistency, Availability, Partition Tolerance). Понимание этого ограничения очень помогает менеджерам, владельцам продуктов и бизнесу принимать осознанные решения о том, какие свойства системы важнее для конкретного бизнеса.
Я бы выбрал "показать ошибку" :) Лучше показать клиенту ошибку, чем ошибочный баланс.
История и суть¶
В 2000 году Eric Brewer, профессор UC Berkeley, выступил на симпозиуме по принципам распределенных вычислений с гипотезой, которая позже стала теоремой. В 2002 году Seth Gilbert и Nancy A. Lynch из MIT формально доказали её: Perspectives on the CAP Theorem.
Формулировка: В распределённой системе невозможно одновременно обеспечить все три свойства:
| Свойство | Что это значит |
|---|---|
| C — Consistency (Согласованность) | Все пользователи видят одни и те же данные в один момент времени. Если клиент обновил профиль, все другие клиенты сразу видят изменения. |
| A — Availability (Доступность) | Система отвечает на любой запрос, даже если часть инфраструктуры сломалась. "Сайт работает" - даже если медленно или с устаревшими данными. |
| P — Partition Tolerance (Устойчивость к разделению) | Система продолжает работать, когда связь между частями сети нарушена. Это не "хочу/не хочу", а реальность: сетевые сбои неизбежны . |
Ключевой момент: когда происходит сетевой раздел (partition), система должна выбрать между Consistency и Availability. Отказаться от Partition Tolerance нельзя, в распределённой системе сбои связи случаются всегда.
Почему "CA-системы" миф¶
Иногда можно услышать о "CA-системах" (Consistent + Available, но не Partition Tolerant). Это чистый маркетинг. В распределённой системе сетевые разделы неизбежны, поэтому реальный выбор только между CP и AP.
Но, справедливости ради, уточню: CA-система существует, и это не распределённая система, а одна нода. Если бизнесу нужна CA (идеальная согласованность + идеальная доступность), значит, бизнесу не нужна распределённая архитектура.
Три типа систем на практике¶
CP-системы: согласованность прежде всего¶
При сетевом разделе система отказывает в обслуживании, чтобы не рисковать целостностью данных.
Примеры: - PostgreSQL, MySQL в режиме синхронной репликации - MongoDB (в конфигурации по умолчанию) - Redis Cluster - ZooKeeper
Бизнес-сценарии: - Банковские системы: лучше отказать в операции, чем позволить двойное списание средств. - Системы бронирования: продать один и тот же билет двум людям недопустимо. - Управление запасами: оверселлинг (продажа отсутствующего товара) дороже, чем потеря заказа.
Цена вопроса: простои во время сетевых сбоев. Если дата-центр в Москве потерял связь с дата-центром в Питере, один из них может стать недоступен для записи.
AP-системы: доступность прежде всего¶
При сетевом разделении система продолжает отвечать, даже если данные временно не согласованы между узлами.
Примеры: - Cassandra, DynamoDB - CouchDB - ScyllaDB
Бизнес-сценарии: - Корзина: лучше позволить добавить товар в корзину, чем показать ошибку в пиковую нагрузку (Black Friday). Если товар закончится - разберутся позже. - Ленты социальных сетей: пользователь может временно не увидеть последний пост друга, но приложение не должно "висеть". Лучше показать старую ленту, чем не показать ничего. - Системы аналитики: отчёт за вчера с небольшой погрешностью лучше, чем никакого отчёта.
Цена вопроса: временная несогласованность данных. Пользователь может увидеть "старые" данные или столкнуться с конфликтами, которые система разрешит позже.
"CA-системы": когда это работает¶
Единственный способ получить CA это отказаться от распределённости. Однонодовая база данных на одном сервере - это как раз и есть CA-система. Но как только вам потребуется отказоустойчивость (резервирование, геораспределение), вы автоматически попадаете под действие CAP-теоремы.
Проблемы CAP-теоремы: почему её недостаточно¶
CAP-теорема это фундамент, но фундамент не строят из одного кирпича. За два десятилетия исследователи и практики нашли в ней ограничения и предложили дополнения. Важно понимать не только саму теорему, но и её границы:
Проблема 1: бинарность "доступности"¶
CAP считает систему "доступной", если она вообще отвечает. Система, которая отвечает через 30 минут, формально доступна по CAP. Очевидно, для бизнеса это бесполезная метрика, потому что клиенты уйдут и напишут гневный пост в соцсетях раньше, чем дождутся ответа. Для бизнеса это эквивалентно недоступности. CAP не различает "ответил за 50 мс" и "ответил через 5 минут", все равно же ответил.
Проблема 2: только один вид согласованности¶
Согласованность тоже бывает разной CAP использует самую строгую модель — линеаризуемость (linearizability), когда все видят одни и те же данные мгновенно. Но на практике существуют десятки градаций согласованности, например:
- Я вижу свои изменения (Read-your-writes): важный компромисс для пользовательских профилей, "я вижу свои изменения, другие могут видеть старые данные".
- Данные сойдутся через несколько секунд (Eventual consistency): допустимо для счётчиков лайков.
- Строгая согласованность (Strong consistency): обязательно для баланса счёта.
CAP не помогает выбрать между ними.
Проблема 3: ничего не говорит о нормальной работе¶
Самое важное ограничение: CAP описывает поведение только при сетевом сбое. А сбои это исключительная ситуация, а не повседневность. Что происходит в 99,9% времени, когда сеть работает нормально? CAP молчит.
PACELC: расширение CAP для реального мира¶
В 2010 году Daniel J. Abadi предложил PACELC, теорему, которая решает эти проблемы и отвечает на вопрос "а что в обычные дни?".
Формулировка:
Если в системе есть Partition (раздел), она должна выбрать между Availability (доступностью) и Consistency (согласованностью) - как в CAP.
Else (иначе, при нормальной работе), система должна выбрать между Latency (латентностью) и Consistency (согласованностью).
Простая формулировка: - Если случился сбой: выбираем между доступностью и согласованностью (это мы уже знаем из CAP). - А если всё работает нормально: выбираем между скоростью отклика и согласованностью.
Второй выбор часто важнее для бизнеса. Потому что сбои случаются редко, а скорость работы влияет на пользователя каждый день.
CAP-теорема говорит о том, что происходит во время сбоя. PACELC добавляет важное уточнение: а что происходит всё остальное время? Оказывается, даже без сбоев мы всё равно делаем выбор между скоростью и точностью.
Даже без сетевых сбоев распределённая система сталкивается с дилеммой:
- Высокая согласованность: нужно дождаться подтверждений от нескольких узлов перед ответом клиенту. Это увеличивает время отклика (latency).
- Низкая latency: отвечаем сразу, не дожидаясь синхронизации с другими узлами. Но рискуем отдать клиенту устаревшие данные.
Этот выбор между скоростью и точностью стоит перед любой реплицированной системой каждый день, не только во время сбоев.
Четыре квадранта PACELC¶
PACELC даёт четыре комбинации выбора:
| Классификация | При разделе (P) | При нормальной работе (E) | Примеры систем | Возможность настройки | Бизнес-профиль |
|---|---|---|---|---|---|
| PC/EC | Consistency | Consistency | ZooKeeper, CockroachDB (строгий режим), Google Spanner, VoltDB | Низкая | Финансы, бронирование, координация кластеров. Готовы жертвовать скоростью и доступностью ради точности. |
| PA/EL | Availability | Latency | Cassandra, Amazon DynamoDB, ScyllaDB (по умолчанию), Riak | Средняя (настройка quorum) | Социальные сети, аналитика, IoT, рекомендательные системы. Скорость и доступность важнее мгновенной точности. |
| PA/EC | Availability | Consistency | MongoDB (с read preference), MySQL (асинхронная репликация), Cassandra (с quorum), Kafka (с синхронным продюсером) | Высокая | E-commerce, корзина товаров, пользовательские сессии, кэши. Баланс между точностью и доступностью. |
| PC/EL | Consistency | Latency | Редко встречается на практике, возможен в системах с кастомными настройками | Низкая | Теоретически: системы аналитики, где сбои не критичны, но в норме нужна максимальная скорость. |
Разбор на примерах¶
PC/EC: "Банкиры" - Google Spanner: глобально распределённая SQL-база с атомарными транзакциями. - Цена: высокая латентность (синхронная репликация через полушария), возможны простои при сетевых сбоях. - Почему: в банковском деле ошибка стоит дороже задержки.
PA/EL: "Социальные сети" - ScyllaDB/DynamoDB: отвечают за миллисекунды, доступны всегда, данные сходятся "со временем". - Цена: пользователь может увидеть свой пост, а другой ещё нет; счётчик лайков может отставать. - Почему: пользователь предпочтёт быстрый ответ с небольшой погрешностью ожиданию.
PA/EC: "Универсалы" - MongoDB: по умолчанию читает с мастера (согласованность), но при сбое переключается на реплики (доступность). - Гибкость: можно настроить под конкретный use-case.
Для понимания: Синхронная репликация: ждём подтверждения от всех узлов, то есть, высокая согласованность, но очень медленно. Асинхронная репликация: отвечаем сразу, это очень быстро, но данные на узлах могут временно расходиться.
Как это применять в работе SRE¶
1. Классификация существующих систем¶
Проведите аудит: какие системы у вас PC/EC, какие PA/EL? Соответствует ли это бизнес-требованиям?
2. Ожидания при сбоях¶
Если у вас CP-система, при сетевом разделе она станет недоступна для записи. Готов ли бизнес к этому? Нужны ли fallback-механизмы?
Если AP-система, то готовы ли вы разбирать конфликты данных после восстановления связи? Нужны ли компенсирующие транзакции?
3. Настройка под требования¶
Многие современные системы (Cassandra, MongoDB, Kafka) позволяют настраивать уровень согласованности per-query:
- Запрос баланса счёта с согласованностью QUORUM (PC).
- Запрос рекомендаций с ONE (PA/EL).
4. Мониторинг SLI¶
PACELC подсказывает, какие метрики важны: - Для PC/EC: RTO/RPO при сбоях, latency на запись. - Для PA/EL: процент "устаревших" чтений, время достижения согласованности (convergence time).
Итого¶
-
CAP это не выбор "два из трёх" при проектировании, а выбор "одно из двух" при сбое. Partition Tolerance неизбежен в распределённой системе.
-
PACELC добавляет повседневную реальность: даже без сбоев вы платите за согласованность латентностью.
-
Нет "правильного" выбора, есть выбор, соответствующий бизнес-целям:
- Финансы → PC/EC
- Контент/медиа → PA/EL
-
E-commerce → PA/EC или гибрид
-
Современные системы позволяют тюнинг: не принимайте архитектурные решения "навсегда", а настраивайте их под конкретные операции и под конкретные требования.
-
SRE должен переводить на бизнес-язык: вместо "у нас AP-система" говорить "при сетевом сбое корзина продолжит работать, но есть 0,1% риска оверселлинга, который мы компенсируем резервированием склада" или вместо "у нас CP-система" говорить "если сломается связь между дата-центрами, запись будет недоступна 10–15 минут. Какой у нас есть план Б?"
Или вообще вот так: Вместо: "Я предлагаю использовать Cassandra, потому что это AP-система". Говорить: "Если мы выберем Cassandra, наша платформа будет очень быстро отвечать пользователям и выдержит любые пиковые нагрузки. Но есть нюанс: если произойдёт сбой связи между серверами, данные могут временно разойтись. Например, пользователь может увидеть, что заказ оформлен, а в соседнем дата-центре эта информация появится через 2–3 секунды. Это нормально для нашей корзины, но не подойдёт для платёжного шлюза. Для платежей я предлагаю использовать отдельную базу с синхронной репликацией, она будет чуть медленнее, но ошибок не допустит".
Глоссарий для менеджера¶
- Сетевое разделение (Partition): ситуация, когда части распределённой системы не могут общаться друг с другом из-за сетевого сбоя.
- Линеаризуемость: самая строгая форма согласованности, когда система ведёт себя как одна машина, все операции мгновенны и атомарны.
- Кворум: минимальное число узлов, которое должно подтвердить операцию для её считающейся успешной.
- Компенсирующая транзакция: операция, откатывающая или корректирующая изменения, внесённые во время сетевого раздела.
Что происходит с CAP сегодня: новые технологии не отменяют физику¶
Некоторые продавцы обещают "идеальную согласованность без потери скорости". Это маркетинг. Физика остаётся физикой: свет в оптоволокне распространяется с конечной скоростью, а сигналу между дата-центрами нужно время.
Однако технологии развиваются в двух направлениях:
1. Сокращение времени обнаружения сбоев Современные сетевые технологии позволяют обнаружить разрыв связи между серверами за микросекунды, а не секунды. Это сокращает окно, когда система находится в "режиме выбора" между доступностью и согласованностью. Но сам выбор никуда не девается.
2. Умные компромиссы Современные базы данных (CockroachDB, YugabyteDB, Google Spanner) научились автоматически переключать уровень согласованности в зависимости от расстояния между узлами. Например: - Запросы внутри одного дата-центра работают с полной согласованностью. - Запросы между континентами могут работать с чуть более слабой гарантией, но с приемлемой скоростью.
Это не отмена CAP, а интеллектуальное управление компромиссами.
Вывод для бизнеса: не гонитесь за идеалом¶
Технологии развиваются, но фундаментальное ограничение остаётся: вы не можете одновременно иметь идеальную согласованность, идеальную доступность и идеальную скорость.
Ваша задача как руководителя — не требовать "и то, и другое, и третье", а понять, что для вашего бизнеса критично, а чем можно пожертвовать.
Вопросы, которые стоит задать команде: - Где в нашем продукте ошибка стоит дороже задержки? (тут нужна строгая согласованность) - Где задержка стоит дороже ошибки? (тут нужна скорость) - Какие операции можно обрабатывать асинхронно, а какие — синхронно?
Ответы на эти вопросы важнее, чем знание того, какая база данных относится к какому квадранту PACELC. Технологии приходят и уходят, а понимание бизнес-компромиссов остаётся навсегда.
Для углублённого изучения¶
Исследователи из MIT предложили CAL-теорему, которая заменяет бинарный "сбой/норма" на количественную меру "видимой задержки". Это интересно с академической точки зрения, но для большинства бизнес-решений достаточно понимания CAP и PACELC.