Чтение
собственных записей

Почему старое имя возвращается?

Приложение может хранить несколько копий данных, чтобы обслуживать чтения на нескольких машинах. В системе ниже записи идут в основную копию — к лидеру. Две другие копии, реплики A и B, получают изменения через репликацию. Последующее чтение приложение может направить на любую реплику.

Репликация здесь асинхронная: лидер подтверждает сохранение до применения изменений репликами. Если страница профиля читает отстающую реплику, она показывает старое имя. Запись успешно выполнена на лидере; копия, обслуживающая чтение, ещё не догнала его.

Инженерный вопрос: как следующему запросу учесть сохранение, об успехе которого вам только что сообщили?

Что обещает чтение собственных записей?

После подтверждения записи последующие чтения должны возвращать состояние, включающее эту запись или более позднее обновление. Это гарантия сессии: она связывает ваши собственные операции. Она не требует актуальности всех реплик для всех пользователей.

Здесь сессия представлена запомненной минимальной версией. Если сохранение подтверждено как v1, следующее чтение с гарантией сессии требует v1 или новее. Реплика с v0 пока не может ответить. Версия — порядковый номер, а не время в миллисекундах.

Сравните мгновенное чтение и чтение, требующее вашу запись. Сначала предскажите: если выбранная реплика отстаёт, вернуть старое имя, ждать или направить запрос в другое место? Затем заблокируйте репликацию, чтобы узнать цену ожидания. Только Следующий шаг двигает время; обычно обновления приходят через два шага.

Предскажите следующий экран

Если задержка репликации вам пока незнакома, начните с урока Репликация и устаревшие чтения. Здесь вы — единственный клиент. Все реплики начинают с Hello версии v0.

Запишите New name. Лидер подтверждает v1, а сессия запоминает минимум v1. Что должна сделать каждая политика чтения до продвижения времени?

1. Выберите реплику B и нажмите Прочитать сразу. Она вернёт Hello, v0. Запрос не требовал версии выше v0.
2. Нажмите Прочитать свою запись. На B версия v0, а запрос требует минимум v1, поэтому значение не возвращается.
3. Выполните один шаг. Чтение продолжает ждать. Ещё один шаг: B применяет v1, и тот же ожидающий запрос завершается со значением New name.

Обе политики используют одну реплику и одно расписание репликации. Отличается условие возврата значения.

Передайте подтверждение дальше

В этой модели каждая подтверждённая запись сохраняет свою версию в сессии клиента. Чтение с гарантией сессии передаёт этот минимум выбранной реплике. Реплика может ответить, только когда применённая версия не ниже требуемой. Само ожидание не продвигает время и не ускоряет репликацию.

Read-your-writes не даёт клиенту прочитать состояние старее его собственных предшествующих подтверждённых записей. Эта гарантия не обещает актуальность всех реплик или вечное сохранение конкретного старого значения: более поздние записи могут его заменить. Показанный результат фиксирует версию и состояние лидера на момент завершения; после новой записи он остаётся историческим.

Нарушьте быстрый сценарий

Сбросьте эксперимент, заблокируйте B, запишите New name и выполните два шага. A догонит лидера, B останется на v0. Мгновенное чтение с B всё ещё вернёт Hello. Чтение с гарантией сессии на B будет ждать, хотя A уже могла бы ответить.

Выполните ещё несколько шагов. Ожидание не исправляет заблокированную связь. Восстановите B: чтение всё ещё ждёт. Ещё один шаг применит просроченные сообщения, и чтение завершится автоматически. Другой вариант: нажмите Отменить ожидающее чтение, выберите A и отправьте туда новый запрос с гарантией сессии. Отмена не возвращает значение и сохраняет минимум сессии.

Какова цена гарантии?

Мгновенное чтение предпочитает быстрый ответ выбранной реплики, даже если данные старее вашей записи. Требование увидеть свою запись лишает вас немедленного ответа при отставании реплики. Если связь репликации заблокирована навсегда, эта модель ждёт бесконечно; старое имя не выдаётся как успешный результат чтения с гарантией сессии.

Реальные приложения должны выбрать предельное время ожидания и дальнейшее действие: сообщить о недоступности, повторить запрос в другом месте или использовать другой маршрут чтения, удовлетворяющий требованию. Здесь доступны явная отмена и ручной выбор другой реплики после неё. Автоматического переключения и таймаута нет. Чтение с лидера — ещё один вариант со своими предположениями о маршрутизации и отказах.

Границы модели

• Один последовательный клиент, один строковый ключ, постоянный лидер и две реплики. Все записи принадлежат этому клиенту; нет параллельных клиентов и передачи токенов между сессиями.
• Запись сразу подтверждается лидером и повышает минимум сессии. Это модель видимости, а не доказательство надёжного хранения.
• Версии растут при каждой принятой записи, даже с тем же значением. Пустые записи отклоняются; пробелы по краям удаляются, длина ограничена 80 символами.
• Используется исходная детерминированная модель репликации: сообщения доставляются через два логических шага, в FIFO-порядке для каждой реплики и сохраняются при блокировке. Только Следующий шаг двигает время. Блокируется связь репликации, а не узел и не вся сеть.
• Одновременно допускается одно ожидающее чтение. Реплика и минимум фиксируются при запросе. Запись и новые чтения недоступны до завершения или отмены; управление репликацией остаётся доступным.
• Чтение с гарантией сессии завершается на шаге, когда выбранная реплика применила требуемую версию. Восстановление связи само по себе не доставляет сообщения. Мгновенное чтение никогда не ждёт минимума сессии.
• Нет автоматических таймаутов, переключения при отказе, маршрутизации, выборов, постоянного хранения, многоключевых транзакций и полного протокола причинной согласованности. Сброс и перезагрузка удаляют состояние. Логические шаги не являются бенчмарком задержки.

Обсудите при проектировании

Сохранение успешно, но выбранная реплика отрезана от репликации. Что допустимо для вашего продукта: старое имя, индикатор ожидания, явная ошибка или обращение к другой реплике? Где хранится минимальная версия, как она передаётся следующему запросу и сколько он может ждать?

Источники и дальнейшее чтение

Урок, диаграмма и эксперимент — авторские. Механизм минимальной версии — объясняющий приём для этой одноключевой модели, а не реализация протокола базы данных.

В качестве конкретного примера MongoDB описывает read-your-writes в причинно согласованных сессиях при использовании majority read/write concerns и последовательных операций сессии. Эти условия и другие гарантии относятся к MongoDB, а не к симулятору. См. изоляцию чтения, согласованность и актуальность, включая гарантии и ограничения сессий (проверено 26.10.2026).