Хорошо, давайте представим, что у вас есть распределенная база данных. Допустим, у вас есть узел в Орегоне и один в Калифорнии. Теория CAP говорит, что вы столкнетесь с проблемами при настройке этого типа базы данных.
Например, если вы запрашиваете данные из одной базы данных, они должны совпадать с данными в другой базе данных. Это гарантирует, что любое значение, которое вы имеете в одной базе данных, гарантированно будет в другой ( непротиворечивость теории CAP). Это позволяет обновлять данные в одной базе данных и запрашивать их из другой, получая те же результаты.
Когда мы обновляем данные в узле Орегон, данные отправляются в калифорнийский узел, чтобы базы данных были согласованными. Чтобы по-настоящему поддерживать согласованность, мы должны убедиться, что обе базы данных получают обновление, прежде чем любой из них сможет действительно сохранить данные (двухфазное принятие с использованием распределенных транзакций). Другими словами, если база данных Калифорнии не может сохранить данные по какой-либо причине (например, сбой жесткого диска), то база данных в Орегоне не сохранит данные и завершит транзакцию.
Проблема с распределенными транзакциями, подобная описанной выше, возникает, когда мы хотим иметь высокую доступность. В приведенном выше сценарии процесс синхронизации обеих баз данных очень и очень медленный. (Представьте себе, мы должны отправить данные из Орегона в Калифорнию, убедиться, что они туда попадают, убедиться, что обе базы данных имеют блокировки данных и т. Д.) Это вызывает серьезные проблемы, когда мы хотим, чтобы система была быстрой и отзывчивой даже во время времена высокого спроса. (Это Доступность теоремы CAP.)
Обычно для обеспечения высокой доступности мы используем репликацию вместо распределенных транзакций. Таким образом, вместо того, чтобы гарантировать, что Калифорния может принять данные, мы просто сохраняем их в узле Орегона, а затем отправляем данные в Калифорнию, когда мы их получаем. Это гарантирует, что мы всегда можем хранить данные, независимо от того, готова ли Калифорния хранить данные или нет.
Это улучшает доступность, но за счет согласованности. Посмотрите, если кто-то обновляет данные в Орегоне, а затем кто-то (одновременно) читает данные в Калифорнии, они не получают новые данные - базы данных больше не согласованы. На самом деле, они не будут согласованы, пока Орегон не отправит данные в Калифорнию!
Итак, это компромисс между доступностью и согласованностью.
Допуск раздела - это третий аспект теории CAP. В этом контексте разбиение является идеей о том, что база данных (или другая распределенная система) может разбиваться на отдельные разделы и при этом функционировать правильно.
Возникает вопрос: что происходит, когда обе базы данных работают правильно, но связь между Орегоном и Калифорнией разорвана?
Если мы обновляем базу данных в Орегоне, нам нужно так или иначе доставить данные в Калифорнию (распределенная транзакция или репликация). Однако, если связь между ними разорвана, то система становится разделенной, и базы данных больше не связаны друг с другом.
Когда это происходит, вы можете отказаться от предоставления обновлений (для обеспечения согласованности) за счет доступности или разрешить обновления (для поддержания доступности) за счет согласованности.
Как видите, допуск раздела создает прямой компромисс между согласованностью и доступностью.
Очевидно, в этом есть нечто большее, но это пара примеров того, как эти три основных аспекта распределенных систем работают друг против друга. Объяснение теории CAP Джулианом Брауном - отличное место, чтобы узнать больше.