CAP theorem — это теорема про распределённые системы: базы данных, кластеры, микросервисы, репликации, когда данные лежат не на одной машине, а на нескольких узлах.
Она говорит: при сетевом разделении система не может одновременно гарантировать все три свойства:
C — Consistency / согласованность
Все узлы видят одни и те же актуальные данные.
Например: если ты записал balance = 100, то любой последующий запрос к любому узлу должен увидеть именно 100, а не старое значение.
A — Availability / доступность
Каждый запрос получает ответ, даже если часть системы сломалась или недоступна.
Не обязательно «правильный самый свежий» ответ, но система не падает и не говорит: «не могу обслужить».
P — Partition tolerance / устойчивость к разделению сети
Система продолжает работать, даже если между узлами пропала связь.
Например, дата-центр А не видит дата-центр Б, но оба ещё живы.
Главная суть не в том, что «можно выбрать только два из трёх» вообще. Это популярное, но немного туповатое упрощение.
Более точная формула такая:
Если в распределённой системе случилось сетевое разделение, тебе приходится выбирать: либо сохранять строгую согласованность, либо сохранять доступность.
То есть P в реальном распределённом мире почти не выбирается. Сеть может ломаться. Пакеты могут теряться. Узлы могут временно не видеть друг друга. Поэтому вопрос обычно такой:
Когда случился partition, что важнее: не отвечать, чтобы не соврать, или отвечать, рискуя временной рассинхронизацией?
Выбирает Consistency + Partition tolerance.
Если узлы не могут синхронизироваться, система может отказать в операции, чтобы не выдать противоречивые данные.
Пример логики:
Лучше временно не принять запись, чем принять две конфликтующие версии истины.
Это подходит там, где нельзя допустить расхождение: банковские операции, блокировки, критичные транзакции.
AP-система
Выбирает Availability + Partition tolerance.
Даже если часть узлов не видит другую часть, система продолжает отвечать. Но данные могут временно разойтись, а потом согласоваться.
Пример логики:
Лучше ответить сейчас, даже если данные временно не идеально свежие.
Это подходит для лайков, просмотров, кэшей, фидов, некоторых пользовательских действий, где временная рассинхронизация допустима.
Простой пример
Есть два сервера:
- сервер A в Москве;
- сервер B в Берлине.
Пользователь записал новое значение на сервер A.
Но между A и B пропала сеть.
Теперь другой пользователь обращается к серверу B.
Варианты:
CP-поведение:
B говорит: «Я не уверен, что у меня свежие данные, поэтому не отвечу / откажу в операции».
Согласованность сохранена, доступность потеряна.
AP-поведение:
B отвечает тем, что у него есть.
Доступность сохранена, но данные могут быть устаревшими.
Главное различение
CAP — это не про «какая база лучше».
Это про онтологический выбор системы в момент разрыва связи:
- или система защищает единую истину;
- или система защищает непрерывность ответа.
В нормальном состоянии, когда сеть работает, система может выглядеть и согласованной, и доступной. Но CAP проявляется именно в момент сбоя связи между частями системы.
Нужно разделять стандартый и имплементацию
