Для различных задач в рамках одной системы могут быть развернуты несколько разных или одинаковых СУБД (например, при подходе database per service). Набор хранящихся данных в них может частично пересекаться, что порождает проблемы, известные как CAP-теорема Брюера:
Согласованность (Consistency) — в один момент времени данные во всех узлах одинаковы (не противоречат друг другу).
Доступность (Availability) — каждый запрос к корректно работающему узлу завершается корректным ответом, но без гарантии, что ответы всех узлов системы совпадают.
Устойчивость к разделению (Partition tolerance) — расщепление распределенной системы на несколько изолированных секций не приводит к некорректности отклика каждой из секций.
CP-системы (Согласованность + Устойчивость к разделению)
Жертвуем: Доступностью (Availability).
Как работают: Если сеть разорвана, система блокирует запись/чтение на некорректных узлах, чтобы не допустить рассинхрона. Вы можете получить ошибку "Service Unavailable", но данные останутся точными.
Где используют: Банки, платежные системы, системы бронирования авиабилетов (здесь критична точность денег/мест).
Примеры СУБД: MongoDB (по умолчанию, при шардировании), HBase, Redis (в кластерном режиме), ZooKeeper, PostgreSQL (с синхронной репликацией).
Пример из жизни: Вы пытаетесь перевести 1000 рублей другу во время обрыва интернета у банка. Банк скажет "Ошибка, попробуйте позже" (откажет в доступности), но ваши деньги не пропадут и не продублируются (сохранит согласованность).
AP-системы (Доступность + Устойчивость к разделению)
Жертвуем: Согласованностью (Consistency) — переходим в режим «eventual consistency» (итоговая согласованность).
Как работают: Если сеть разорвана, каждый узел продолжает принимать запросы от своих клиентов. Временно данные расходятся, но как только связь восстанавливается, система их синхронизирует.
Где используют: Социальные сети (лайки, комментарии), поисковые системы, рекомендательные сервисы, интернет-магазины (корзина, отзывы). Здесь скорость и доступность важнее микро-точности.
Пример из жизни: Вы поставили лайк под постом ВКонтакте, а через секунду обновили страницу — лайк пропал, но через 2 секунды появился. Система была доступна всегда (не выдала ошибку), но данные были несогласованны пару секунд.
CA-системы (Согласованность + Доступность)
Жертвуем: Устойчивостью к разделению (Partition Tolerance).
Как работают: Это классические односерверные базы данных (или кластеры, работающие как единое целое внутри одной локации). Если сеть падает или сервер ломается — система падает целиком.
Где используют: Внутренние корпоративные системы, ERP, CRM с одним сервером, где простой лучше, чем рассинхрон данных.
Примеры СУБД: MySQL (без репликации), PostgreSQL (standalone), Oracle (single instance).
Пример из жизни: Вы нажимаете "Мне нравится". Система мгновенно обрабатывает запрос на единственном сервере и сохраняет ваш лайк. Вы обновляете страницу через секунду — лайк горит, счетчик увеличился на 1. Вы обновляете еще раз — все на месте. Через минуту, через час, через день — лайк никуда не пропал и не дублировался.
Важно: В реальности архитекторы говорят, что CA-системы не существуют в распределенной среде, потому что сетевой сбой (P) произойдет неизбежно. Поэтому на практике все распределенные системы — это либо CP, либо AP.
Все три системы в одном приложении (Интернет-магазин)
Внутри одного сайта работают все три подхода одновременно:
CA (корзина товаров): Пока вы заходите в личный кабинет, сервер один. Данные о вашей истории заказов строго согласованы. Если сервер упадет — вы увидите ошибку, но ложных данных не будет.
CP (остаток товара при оформлении): Когда вы кладете товар в корзину и нажимаете "Оформить заказ", система строго резервирует этот конкретный товар, чтобы его не купили одновременно 5 человек. Если база не отвечает — система откажет в оформлении, чтобы не было двойных продаж.
AP (отзывы и рейтинги): Количество звездочек у товара и последний отзыв — это AP. Если вы написали отзыв, а он появился только через 5 минут — это нормально. Система была доступна, но данные немного задержались в синхронизации.
Реальные кейсы применения
Компания/Сервис
Выбор по CAP
Почему?
Банковские системы
CP
Ошибка в балансе стоит миллионов. Проще показать "Сервис временно недоступен".
Amazon (корзина)
AP
Потеря продаж из-за недоступности корзины хуже, чем редкий рассинхрон товаров.
Google Spanner
"Внешне CA" (фактически CP)
Высокая доступность с глобальной согласованностью через атомарные часы и GPS.
Kafka
AP
Очереди сообщений допускают дублирование/потерю, но должны быть всегда доступны.
CAP-теорема на практике — это не догма, а инструмент для осознанного проектирования. Она напоминает, что идеальных систем не бывает, и за каждое преимущество нужно платить. Хороший архитектор не пытается "обойти" CAP, а выбирает правильный компромисс, который минимизирует ущерб для бизнеса.