Две копии данных работают, но перестали обмениваться сообщениями. На условном примере объясняем выбор между согласованным результатом и доступностью операции.
Когда обе площадки работают, а обмена нет
Представим условную систему записи на мастерскую. Сведения о свободном месте хранятся на двух площадках. Первая подтвердила бронь последнего места, но связь между площадками оборвалась до передачи изменения. Вторая площадка продолжает принимать обращения и видит прежнее свободное место.
Сервер здесь не обязательно сломан: он может исправно выполнять локальную работу и отвечать посетителям. Не хватает другого — знания о подтверждённых изменениях на соседней стороне. Такая потеря обмена между частями системы называется сетевым разделением. Вопрос о допустимом ответе в этих условиях и приводит к теореме CAP.
Что означают три буквы
CAP связывает согласованность, доступность и устойчивость к сетевому разделению. В исходной работе Сета Гилберта и Нэнси Линч согласованность описывает поведение, соответствующее единой последовательной копии: уже завершённое изменение нельзя игнорировать при последующем чтении.
Доступность в этой модели означает, что запрос к исправному узлу получает результат операции. Простое сообщение об ошибке не превращает отклонённую операцию в доступную. Устойчивость к разделению означает учёт ситуации, когда сообщения между группами узлов теряются. Это строгие свойства модели, а не проценты из коммерческого соглашения о работе сервиса.
Почему нельзя угадать чужое изменение
Вернёмся к последнему месту на мастерской. Для второй площадки две ситуации выглядят одинаково: либо сосед уже подтвердил бронь, либо никто ещё не записался. Сообщений нет в обоих случаях. Если площадка выдаст подтверждение новой брони, она может обещать место двум людям.
Если же она откажется подтверждать запись без согласования, часть посетителей временно не сможет выполнить действие. Ускорение локального компьютера не даст ему отсутствующее сообщение. Именно невозможность гарантировать одновременно оба свойства при таком разрыве составляет суть компромисса, а не недостаток конкретного приложения.
Как описать приемлемое поведение
Для условной мастерской можно заранее выбрать разные правила для разных действий. Просмотр описания занятия разрешить по локальным сведениям, а окончательное подтверждение единственного места выполнять только там, где обеспечивается нужное согласование. Тогда часть страницы останется полезной, хотя запись может временно приостановиться.
Это пример обсуждения требований, а не универсальный рецепт устройства бронирования. Если разрешать независимые подтверждения по обе стороны разрыва, нужно отдельно определить, как обнаруживать и разбирать конфликт. Последующая сверка не отменяет факта, что два человека уже могли получить несовместимые обещания. Цена такого события зависит от задачи.
Почему лозунга «выберите любые два» мало
Разрыв сети нельзя убрать одним пожеланием к базе. При исправной связи система может обеспечивать и согласованное чтение, и успешные обращения; CAP не требует постоянно ухудшать что-то одно. В последующей работе тех же авторов обсуждаются определения и практические границы этого компромисса.
Не стоит присваивать всему продукту одно свойство по названию технологии. Поведение зависит от операции, режима и конфигурации. Отложенное распространение обновления при обычной работе тоже не доказывает сетевое разделение: причины различия копий нужно проверять. Важны наблюдаемая ситуация и конкретные гарантии, которые обещаны читателю или отправителю данных.
Какие вопросы задать проектировщику
Для обсуждения системы полезно сформулировать три вопроса. Какое действие нельзя подтверждать по устаревшим сведениям? Какие ответы допускают временную задержку обновления? Что увидит пользователь, если нужное согласование недоступно? Затем стоит проверить эти договорённости на учебном сценарии разрыва, включая восстановление связи.
При восстановлении обмена нужно понимать, какие операции были приняты и как согласуются изменения. Теорема сама не выдаёт план восстановления и не выбирает механизм разрешения конфликтов. Этим занимается архитектор данных вместе с командой, исходя из требований к продукту.
От понятия к устройству системы
CAP помогает увидеть границу обещаний: нельзя объявить каждый ответ одновременно всегда доступным и строго согласованным, не учитывая потерю связи. При выборе архитектуры полезно отдельно описывать хранение, обмен и поведение операций. Например, озеро и хранилище данных различаются назначением и не дают готового ответа на вопрос о CAP.
Разбирать такие решения и их связь с задачами бизнеса можно на программе Архитектор данных. Начать стоит с конкретного пользовательского обещания: что именно система обязана сохранить верным при недоступности соседней площадки.
