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