Доступность в этом случае означает, что в случае сетевого раздела , сервер, к которому подключается клиент, может быть не в состоянии гарантировать уровень согласованности, которого ожидает клиент (или что системанастроен на предоставление).
Предполагается, что в гипотетической распределенной системе имеется 3 узла A, B и C.A, B и C каждый работает в своей собственной стойке серверов с двумя коммутаторами между ними:
[Node A] <- Switch #1 -> [Node B] <- Switch #2 -> [ Node C ]
Теперь предположим, что указанная система настроена так, что ГАРАНТИРУЕТСЯ, что любая запись будет выполнятьсякак минимум 2 узла, прежде чем он будет считаться зафиксированным.Теперь давайте предположим, что коммутатор # 2 отключен, и какой-то клиент подключен к узлу C:
[Node A] <- Switch #1 -> [Node B] [ Node C ] <-- Some client
Этот клиент не сможет выдавать согласованные записи, поскольку распределенная система в настоящее время находится в состоянии секционирования.(а именно, узел C не может связаться с достаточным количеством других узлов, чтобы гарантировать требуемую согласованность с 2 узлами).
Я бы добавил к этому, что некоторые базы данных NoSQL позволяют очень динамично выбирать атрибуты CAP.Кассандра, например, позволяет клиентам указывать количество серверов, на которые должна быть сделана запись, прежде чем она будет зафиксирована для каждой записи.Запись на один сервер - это «AP», запись на кворум (или на все) - больше «CA».
EDIT - из комментариев ниже:
В MongoDB вы можетеиметь конфигурацию master / slave только внутри набора реплик.Это означает, что выбор AP против CP делается клиентом во время запроса.Клиент может указать slaveOk, который будет считывать данные с произвольно выбранного ведомого (который может иметь устаревшие данные): mongodb.org/display/DOCS/….Если клиент не в порядке с устаревшими данными, не указывайте slaveOk, и запрос будет передан мастеру.Если клиент не может связаться с мастером, вы получите ошибку.Я не уверен точно, что это за ошибка.