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).

Итого

  1. CAP это не выбор "два из трёх" при проектировании, а выбор "одно из двух" при сбое. Partition Tolerance неизбежен в распределённой системе.

  2. PACELC добавляет повседневную реальность: даже без сбоев вы платите за согласованность латентностью.

  3. Нет "правильного" выбора, есть выбор, соответствующий бизнес-целям:

  4. Финансы → PC/EC
  5. Контент/медиа → PA/EL

  6. E-commerce → PA/EC или гибрид

  7. Современные системы позволяют тюнинг: не принимайте архитектурные решения "навсегда", а настраивайте их под конкретные операции и под конкретные требования.

  8. SRE должен переводить на бизнес-язык: вместо "у нас AP-система" говорить "при сетевом сбое корзина продолжит работать, но есть 0,1% риска оверселлинга, который мы компенсируем резервированием склада" или вместо "у нас CP-система" говорить "если сломается связь между дата-центрами, запись будет недоступна 10–15 минут. Какой у нас есть план Б?"

Или вообще вот так: Вместо: "Я предлагаю использовать Cassandra, потому что это AP-система". Говорить: "Если мы выберем Cassandra, наша платформа будет очень быстро отвечать пользователям и выдержит любые пиковые нагрузки. Но есть нюанс: если произойдёт сбой связи между серверами, данные могут временно разойтись. Например, пользователь может увидеть, что заказ оформлен, а в соседнем дата-центре эта информация появится через 2–3 секунды. Это нормально для нашей корзины, но не подойдёт для платёжного шлюза. Для платежей я предлагаю использовать отдельную базу с синхронной репликацией, она будет чуть медленнее, но ошибок не допустит".

Глоссарий для менеджера

  • Сетевое разделение (Partition): ситуация, когда части распределённой системы не могут общаться друг с другом из-за сетевого сбоя.
  • Линеаризуемость: самая строгая форма согласованности, когда система ведёт себя как одна машина, все операции мгновенны и атомарны.
  • Кворум: минимальное число узлов, которое должно подтвердить операцию для её считающейся успешной.
  • Компенсирующая транзакция: операция, откатывающая или корректирующая изменения, внесённые во время сетевого раздела.

Критика и современные развития

CAP-теорема это фундамент, но фундамент не строят из одного кирпича. За два десятилетия исследователи и практики нашли в ней ограничения и предложили дополнения. Важно понимать не только саму теорему, но и её границы.

Главная проблема CAP: она слишком упрощает реальность

CAP-теорема оперирует бинарными понятиями: "доступна или недоступна", "согласована или не согласована". В реальном мире всё сложнее.

Доступность бывает разной Система, которая отвечает на запрос через 30 секунд, формально считается доступной по CAP. Но для бизнеса это провал. Пользователь уже закрыл вкладку, перешёл к конкуренту и, скорее всего, больше не вернётся. Настоящая доступность измеряется не в "работает/не работает", а в миллисекундах, процентилях и пользовательском опыте.

Согласованность тоже бывает разной CAP рассматривает только самую строгую модель, когда все видят одни и те же данные мгновенно. Но на практике существует множество промежуточных уровней: - Я вижу свои изменения: важный компромисс для пользовательских профилей. - Данные сойдутся через несколько секунд: допустимо для счётчиков лайков. - Строгая согласованность: обязательно для баланса счёта в банках.

CAP не помогает выбрать между этими вариантами.

CAP ничего не говорит о том, что происходит в обычное время Самое важное ограничение: CAP описывает поведение только при сетевом сбое. А сбой это исключительная ситуация, а не повседневность. Что происходит в 99,9% времени, когда сеть работает нормально? CAP об этом не говорит.

PACELC: взгляд на повседневность

Именно поэтому в 2010 году Дэниел Абади предложил PACELC — расширение, которое отвечает на вопрос "а что в обычные дни?".

Простая формулировка: - Если случился сбой — выбираем между доступностью и согласованностью (это мы уже знаем из CAP). - А если всё работает нормально — выбираем между скоростью отклика и согласованностью.

Второй выбор часто важнее для бизнеса. Потому что сбои случаются редко, а скорость работы влияет на пользователя каждый день.

Практический пример Представьте интернет-магазин. В обычный вторник: - Можно настроить базу данных так, чтобы она ждала подтверждения от всех узлов перед ответом. Тогда данные будут идеально согласованы, но покупатель будет ждать ответа на 200 миллисекунд дольше. - А можно настроить так, чтобы она отвечала сразу, не дожидаясь синхронизации. Тогда покупатель получит мгновенный ответ, но есть микроскопический шанс, что данные на разных узлах временно разойдутся.

Какой вариант выбрать? Зависит от того, что важнее: идеальная точность или быстрый пользовательский опыт. Это решение вы принимаете не только во время сбоя, но и каждый день.

Что происходит с CAP сегодня: новые технологии не отменяют физику

Некоторые поставщики обещают "идеальную согласованность без потери скорости". Это маркетинг. Физика остаётся физикой: свет в оптоволокне распространяется с конечной скоростью, а сигналу между дата-центрами нужно время.

Однако технологии развиваются в двух направлениях:

1. Сокращение времени обнаружения сбоев Современные сетевые технологии позволяют обнаружить разрыв связи между серверами за микросекунды, а не секунды. Это сокращает окно, когда система находится в "режиме выбора" между доступностью и согласованностью. Но сам выбор никуда не девается.

2. Умные компромиссы Современные базы данных (CockroachDB, YugabyteDB, Google Spanner) научились автоматически переключать уровень согласованности в зависимости от расстояния между узлами. Например: - Запросы внутри одного дата-центра работают с полной согласованностью. - Запросы между континентами могут работать с чуть более слабой гарантией, но с приемлемой скоростью.

Это не отмена CAP, а интеллектуальное управление компромиссами.

Вывод для бизнеса: не гонитесь за идеалом

Технологии развиваются, но фундаментальное ограничение остаётся: вы не можете одновременно иметь идеальную согласованность, идеальную доступность и идеальную скорость.

Ваша задача как руководителя — не требовать "и то, и другое, и третье", а понять, что для вашего бизнеса критично, а чем можно пожертвовать.

Вопросы, которые стоит задать команде: - Где в нашем продукте ошибка стоит дороже задержки? (тут нужна строгая согласованность) - Где задержка стоит дороже ошибки? (тут нужна скорость) - Какие операции можно обрабатывать асинхронно, а какие — синхронно?

Ответы на эти вопросы важнее, чем знание того, какая база данных относится к какому квадранту PACELC. Технологии приходят и уходят, а понимание бизнес-компромиссов остаётся навсегда.

Для углублённого изучения

Исследователи из MIT предложили CAL-теорему, которая заменяет бинарный "сбой/норма" на количественную меру "видимой задержки". Это интересно с академической точки зрения, но для большинства бизнес-решений достаточно понимания CAP и PACELC.