CAP-теорема описывает комприсс в распределённых системах. Если часть серверов временно не может обмениваться данными с другой частью системы из-за сбоя сети, потери связи или сильных задержек, система должна выбрать приоритет: либо не отвечать на часть запросов, чтобы не вернуть устаревшие или противоречивые данные, либо продолжать отвечать, допуская, что данные на разных серверах могут временно отличаться.
Что такое CAP-теорема? Как она влияет на выбор архитектуры?
Подробный ответ
Три свойства CAP
Consistency— чтение возвращает последнее успешное значение либо ошибку, а не устаревшие данные;Availability— каждый запрос к работающему узлу получает неошибочный ответ;Partition tolerance— система продолжает работать по выбранной модели при потере или задержке сообщений между узлами.
Главная идея
CAP не означает, что система всегда выбирает любые две буквы из трёх. Компромисс становится критичным именно во время сбоя связи между узлами распределённой системы. В реальной распределённой инфраструктуре сбои неизбежны, поэтому архитектура должна решить: при невозможности синхронизации узлов остановить часть операций ради корректности или отвечать дальше, допуская временно устаревшее либо конфликтующее состояние.
Network partition
Node A X Node B
Choose during the split:
- CP: reject unsafe operations
- AP: continue serving, reconcile laterCP-подход
CP-подход предпочитает consistency. Во время сбоя часть запросов может получить ошибку или timeout, если система не может гарантировать корректность. Это подходит для критичных инвариантов: платежей, остатков, уникальных прав доступа, владения lock или выдачи единственного ресурса.
AP-подход
AP-подход предпочитает availability. Система продолжает отвечать, но часть пользователей может временно видеть устаревшие данные. После восстановления связи данные синхронизируют и разрешают конфликты. Это часто допустимо для ленты публикаций пользователя, счётчиков, поиска, рекомендаций и аналитики.
Как применять в архитектуре
Выбор нужно делать не для всей компании и не только для одной базы, а для конкретной операции и инварианта. Полезные вопросы: что недопустимо потерять или нарушить, допустимо ли устаревание данных, как система ведёт себя при сбое и как она восстановит согласованное состояние после сбоя.
Как ответить на собеседовании
CAP говорит, что при сетевом сбое нельзя одновременно сохранить строгую consistency и полную availability. В реальной системе сбои нужно терпеть, поэтому я выбираю компромисс по доменному требованию: для платежей и инвентаря чаще важнее корректность и отказ части операций, а для ленты публикаций или поиска обычно допустима небольшая задержка обновления данных, если это помогает системе оставаться доступной.
Оцени свой прогресс