CAP-теорема и распределённые системы: простыми словами

---

1. Что это (простыми словами)

CAP-теорема отвечает на вопрос, который встаёт перед каждым, кто строит систему больше чем из одного узла: можно ли получить данные, которые и актуальны, и доступны, когда сеть дала сбой.

Формулируется через три буквы:

• C — Consistency (согласованность). Все узлы видят актуальные данные в один момент. Записал в один узел — остальные сразу знают.
• A — Availability (доступность). Каждый запрос получает ответ, даже если какой-то узел недоступен. Система не «падает», а отвечает.
• P — Partition tolerance (устойчивость к разделению сети). Система продолжает работать, даже если часть узлов потеряла связь между собой.

Ключевой вывод теоремы: в распределённой системе с разделением сети нельзя обеспечить одновременно и согласованность, и доступность. Приходится выбирать — жертвовать одним ради другого.

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

2. Как это работает

На практике CAP разворачивается в выбор «что отдать» в моменты сетевого разделения и «как догнать» после него. Два подхода:

CP — согласованность в приоритете. При разделении сети часть узлов недоступна, чтобы не отдать устаревшее. Выбирают там, где цена устаревших данных высока: деньги, остатки, учёт. Пример — финансовый счёт: лучше не отдать вовсе, чем отдать неверный.

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

Полный круг выглядит так:

*запрос → API gateway → распределённый сервис → реплики БД → выбор CP или AP под операцию*

Разделение сети — не абстракция. Оно случается при обычных вещах: сетевая поломка, рестарт узла, деплой, нагрузка, недоступность ЦОД. Поэтому решение CP или AP принимается заранее для каждой критичной операции, а не «в целом по системе».

Посередине помогают промежуточные механизмы: кэширование держит быстрый ответ (частичная доступность), очереди и retry догоняют согласованность позже, а репликация ускоряет чтение и снижает риск потери. Как и когда их включать — в материале шардирование и кэширование.

3. Зачем это нужно интегратору и заказчику

CAP-теорема — не абстрактная теория, а основа для конкретных решений о том, что должно работать всегда и что — быть актуальным. Она прямо формирует бюджет и архитектуру:

• Выбор значений по каждой операции. Если нужны деньги — CP. Если нужен «живой» каталог — AP. Это решение принимает архитектор вместе с бизнесом.
• Требования по доступности. Если выбрали CP, часть узлов при сбое будет недоступна — значит, нужны SLA с честным простоем. Отсюда публичное обещание «N 9s» и расчёт. Подробнее — доступность по SLA.
• Стоимость компромисса. AP даёт меньше простоя, CP — меньше ошибок в данных. Это trade-off, который отражён в том, сколько узлов и какой избыточности заложено.
• Слой API gateway. Именно здесь часто принимается решение, как обрабатывать запрос во время частичного сбоя: отдать устаревшее или подождать. Правильно настроенный gateway — та точка, где «CP» и «AP» по разным сервисам сосуществуют.

4. Связь с оборудованием и каталогом

Выбор CP или AP напрямую влияет на то, какое железо и сколько его нужно:

• Копия данных = больше дисков. Репликация и согласованность требуют дополнительного хранилища: копии и снапшоты. Смотрите системы хранения данных с расчётом ёмкости под реплики.
• Ферма узлов под доступность. Чтобы система жила при отказе узла, нужно N+1 машин. Число узлов — следствие решения из масштабирования и балансировки, и это российские серверы.
• Быстрый канал между репликами. Согласованность и репликация нагружают сеть между узлами. Для распределённого контура нужны коммутаторы с 10/25GbE и L3-маршрутизацией.

Для госзаказчика и компаний с госдолей обязательное условие: серверы, СХД и сетевое оборудование в реестре Минпромторга, иначе распределённый контур не согласовать по 44-ФЗ/223-ФЗ. Логика выбора оборудования под высокую доступность — в переходе на отечественное оборудование.

4.1 Как снизить цену компромисса

CAP не отменяет, а требует грамотной закладки избыточности. Меры, которые смягчают выбор:

• Балансировка на уровне операций. Разные запросы живут в разных режимах: чтение каталога — AP, запись счёта — CP. API gateway управляет этим раздельно.
• Асинхронность. Очереди и retry позволяют согласовать данные «позже», не держа пользователя в ожидании. Пик согласованности смещается в фоновый процесс.
• Репликация + кэш. Реплики ускоряют чтение и снижают риск потери при отказе узла, кэш даёт быстрый ответ на чтении без похода к диску.
• Журналирование. Для операций с CP обязательна запись в лог до подтверждения — тогда восстановление после сбоя детерминировано.

Эти меры перекладывают часть нагрузки с «железа» на архитектуру. Правильно настроенный слой API gateway уже не точка отказа, а место, где режимы CP и AP сосуществуют под одним контуром. Как выстроить этот слой — в архитектуре ПО.

5. Вопросы и ответы

CAP-теорема — это закон, который всегда выполняется? — Незыблемая граница для распределённых систем: на время сетевого разделения нельзя одновременно обеспечить и согласованность, и доступность. Приоритет выбирается на каждую операцию.

Это значит, что нельзя доверять распределённым системам? — Нет. Теорема говорит о компромиссе, а не о невозможности. Если правильно выбрать CP или AP под каждую операцию и честно заложить SLA, система работает надёжно.

Где именно принимается решение CP или AP? — На уровне API gateway и логики каждого сервиса, а не «в общем по системе». Разные операции могут жить в разных режимах.

Как связаны согласованность и репликация? — Репликация — способ догнать согласованность. При быстром копировании копии согласованы почти мгновенно, при отложенном — с задержкой, что и даёт выбор между строгой и слабой согласованностью.

Как CAP влияет на выбор железа? — Напрямую: реплики требуют дополнительных дисков и сетевых каналов, а «N+1» узлов под доступность — больше серверов. Поэтому выбор CP/AP заранее закладывают в топологию и бюджет.