Краткий ответ

Причина — репликационная задержка при асинхронной репликации: запись подтверждена на основной базе, но ещё не применена на реплике. Поэтому чтение с реплики обеспечивает не строгое чтение после записи, а обычно eventual consistency.

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

Исторический контекст

Реплики появились как способ масштабировать чтение, повысить доступность и снизить нагрузку на основной узел транзакционной системы. При синхронной репликации подтверждение записи можно связывать с фиксацией данных на нескольких узлах, но это увеличивает задержку и делает запись зависимой от доступности реплик.

Асинхронная репликация уменьшает задержку записи и сохраняет работоспособность основного узла при проблемах с репликами. Компромиссом становится временное расхождение состояний между узлами.

Постановка проблемы

Пусть запрос изменил профиль пользователя на основной базе и получил успешный ответ. Следующий запрос может попасть на реплику, которая ещё не обработала журнал изменений от основного узла, поэтому пользователь увидит старое имя или прежний статус.

Это особенно опасно для сценариев «записал — сразу прочитал», проверки прав, повторной отправки формы и отображения результата операции. Ошибка обычно проявляется непостоянно: при малой задержке реплика успевает обновиться, а при нагрузке или сетевых проблемах — нет.

Подробное решение

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

Есть несколько вариантов согласования:

Чтение после записи с основного узла — наиболее простое решение для критичных запросов, но оно сохраняет нагрузку на основной узел.
Закрепление пользователя за узлом — после записи запросы пользователя временно направляются на основной узел; это усложняет маршрутизацию и не всегда удобно при смене экземпляров.
Ожидание реплики до нужной позиции журнала — сохраняет чтение с реплики, но добавляет задержку и может завершиться тайм-аутом.
Версионирование данных — ответ на запись содержит версию или позицию изменения, а чтение принимается только от узла, достигшего этой версии.

Нельзя безоговорочно считать чтение с реплики неправильным: для поиска, статистики и многих экранов допустима задержка. Важно явно разделять операции, требующие read-after-write consistency, и операции, которым достаточно согласованности с задержкой.

Синхронная репликация уменьшает окно расхождения, но не устраняет все проблемы: растёт задержка фиксации, а отказ обязательной реплики может остановить запись. Кроме того, несколько реплик могут иметь разное отставание, поэтому простая балансировка чтения между ними не гарантирует одинаковое состояние.

Ситуация из практики

В личном кабинете пользователь менял номер телефона. Команда направляла записи на основной узел, а чтения равномерно распределяла между тремя репликами. После ответа «номер изменён» страница иногда показывала старое значение, из-за чего пользователь повторял операцию.

Рассматривались три варианта. Полностью перенаправить чтение на основной узел было бы просто, но это увеличило бы его нагрузку. Сделать репликацию синхронной означало бы повысить задержку всех записей. Добавить временное чтение с основного узла после изменения профиля сохранило бы производительность остальных запросов, но требовало корректной маршрутизации.

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

Что кандидаты часто упускают

Допустимо ли считать репликацию синхронной гарантией отсутствия устаревших чтений?

Нет, это зависит от конкретной модели и маршрутизации. Даже если запись подтверждается после доставки на реплику, последующее чтение может попасть на другую реплику, которая ещё не достигла той же позиции. Гарантия требует либо чтения с узла, участвовавшего в нужной фиксации, либо механизма проверки версии или позиции репликации.
Почему увеличение числа реплик может ухудшить пользовательское поведение?

Каждая реплика получает изменения с некоторой задержкой, а под нагрузкой задержки могут различаться. Балансировщик начинает распределять запросы между узлами с неодинаковой свежестью, поэтому два последовательных чтения могут вернуть разные версии данных. Большее число реплик также увеличивает объём сетевой передачи и стоимость контроля их состояния.
Чем чтение после записи отличается от строгой сериализуемости?

Read-after-write consistency гарантирует конкретному читателю видимость его успешно выполненной записи в последующих чтениях, но не задаёт полного порядка всех операций между всеми клиентами. Сериализуемость требует, чтобы результат параллельных транзакций был эквивалентен некоторому последовательному выполнению. Поэтому маршрутизация чтения на основной узел может решить проблему устаревшего ответа после записи, но сама по себе не обеспечивает сериализуемую модель для всей системы.