Введение
В современной разработке распределённых систем всё чаще приходится принимать архитектурные решения, которые балансируют между доступностью, согласованностью и устойчивостью к разделению сети (сетевым партициям). Теорема CAP, сформулированная Эриком Брюэрном, утверждает, что в условиях сетевой ошибки невозможно одновременно обеспечить и согласованность (Consistency), и доступность (Availability), и устойчивость к разделению (Partition tolerance) — можно выбрать только два из трёх.
На практике большинство систем обязаны быть устойчивыми к сетевым разделениям (P — mandatory), что оставляет выбор между C и A. Вместо того чтобы пытаться обойти фундаментальные ограничения CAP, разработчики всё чаще прибегают к ослабленным моделям согласованности, в частности — к eventual consistency (в конечном счёте согласованность) и session consistency (согласованность в рамках сессии). Эти модели позволяют сохранить высокую доступность и масштабируемость, при этом сохраняя приемлемый уровень предсказуемости поведения системы.
1. Eventually Consistency — «со временем всё придёт в порядок»
Eventually Consistency — это слабая модель согласованности, при которой система гарантирует, что если обновления прекращаются, то со временем все реплики данных станут идентичными. Это означает, что после записи в одну ноду, другая нода может некоторое время возвращать устаревшее значение, но в конечном итоге — «в конце концов» — она его обновит.
Где это применяется
- Системы типа DynamoDB, Apache Cassandra, Riak.
- Почтовые клиенты, мессенджеры, кэши.
- Приложения, где пользователь не сразу замечает, что данные немного устарели (например, лайки под постом).
Плюсы
- Высокая доступность даже при сетевых сбоях.
- Отличная масштабируемость по чтению и записи.
Минусы
- При чтении сразу после записи возможен возврат старого значения (read-your-writes anomaly).
- Сложность логики приложения, если бизнес-логика требует строгой последовательности.
Практический пример на Java
Представим микросервис для управления профилями пользователей, где обновление аватара может кэшироваться:
Если пользователь сразу после обновления попадёт на другую ноду — он может увидеть старый аватар. Это допустимо в рамках eventual consistency.
2. Session Consistency — «в рамках сессии я вижу то, что сам записал»
Session Consistency — это промежуточная модель между строгой согласованностью и eventual consistency. Она гарантирует, что в рамках одной пользовательской сессии:
- Пользователь видит результат своих собственных записей (read-your-writes).
- Операции выполняются в том же порядке, в каком они были отправлены (monotonic reads и writes).
Это не означает, что другие пользователи сразу увидят изменения — но вы сами не увидите регрессии данных.
Где это применяется
- Веб-приложения с привязкой к сессии (например, через sticky sessions или client-side session tokens).
- Мобильные приложения с локальным кэшем, синхронизирующимся с сервером.
- Системы с привязкой к пользователю, где важно не сбивать его «ощущение реальности».
Почему это «альтернатива» CAP?
Теорема CAP не «обходится» — она фундаментальна. Но вместо борьбы за «C» в условиях «P», мы переопределяем, что значит «согласованность» в контексте конкретного пользователя или сценария.
- Eventually consistency отказывается от мгновенной согласованности в пользу доступности и производительности.
- Session consistency добавляет ограниченную строгую согласованность там, где это важно для UX, сохраняя гибкость в остальной системе.
Это не нарушение CAP — это практическая интерпретация компромисса, признание того, что «строгая согласованность» часто не нужна везде, а только в нужном месте и в нужное время.