Сравните чтение из основной базы и отстающей реплики: какой риск для read-after-write возникает после успешной записи?
После успешной записи чтение с отстающей реплики может вернуть старое состояние данных. Это нарушает гарантию read-after-write: клиент уже записал значение, но немедленный последующий запрос его не видит.
Основной компромисс такой: реплики увеличивают масштабируемость чтения, но при асинхронной репликации могут возвращать устаревшие данные. Если важна свежесть конкретного чтения, его направляют на основную базу, ждут применения записи на реплике или используют механизм согласованной маршрутизации.
Реплики чтения появились как способ разгрузить основную базу при преобладании операций чтения. Вместо увеличения только мощности одного узла запросы распределяют между несколькими копиями данных.
На практике репликация часто выполняется асинхронно: основная база подтверждает запись, не дожидаясь её применения на всех репликах. Это уменьшает задержку записи и позволяет размещать реплики ближе к пользователям, но создаёт окно временной несогласованности.
Пусть клиент изменил адрес доставки и получил успешный ответ. Сразу после этого он запрашивает профиль, а балансировщик направляет чтение на реплику, которая ещё не получила новую запись.
Клиент увидит прежний адрес и может решить, что запись потерялась. В более опасном варианте устаревшие данные приведут к повторному действию, неверному решению пользователя или конфликту при последующем обновлении.
Важно отличать это от полной потери данных. Если основная база сохранила запись, проблема обычно состоит во временной видимости старого состояния, а не в отсутствии записи в системе.
Асинхронная репликация передаёт изменения с некоторой задержкой. Пока реплика не применила нужное изменение, её состояние соответствует более раннему моменту времени, поэтому чтение с неё не обязано отражать только что подтверждённую запись.
Наиболее простой вариант — направлять критичные чтения на основную базу. Он обеспечивает свежесть, но увеличивает нагрузку на основной узел и может повысить задержку или стоимость обслуживания.
Другой вариант — липкая маршрутизация после записи: в течение некоторого периода чтения пользователя отправляются на основной узел. Подход прост, но период должен быть выбран осторожно: слишком короткий не закрывает окно отставания, слишком длинный снижает пользу реплик.
Более точный вариант — передать сведения о позиции или версии записи и читать с реплики только после того, как она достигла этой позиции. Это уменьшает лишнюю нагрузку на основную базу, но требует поддержки метаданных, ожидания и корректного поведения при недоступности или большом отставании реплики.
Синхронная репликация может гарантировать, что запись подтверждается только после фиксации на заданном числе узлов. Цена — большая задержка записи, зависимость от доступности реплик и возможное снижение пропускной способности. Кроме того, синхронная фиксация сама по себе не решает все вопросы маршрутизации и согласованности чтений на уровне приложения.
Мониторинг должен включать репликационное отставание, долю чтений с реплик и число случаев, когда требуемая свежесть не обеспечена. Нельзя считать реплики безопасными для всех чтений только потому, что они обычно отстают на малый промежуток времени: редкие пики задержки часто проявляются именно в пользовательских ошибках.
В интернет-магазине после оформления заказа пользователь иногда видел в личном кабинете статус до оформления. Записи подтверждались основной базой, но чтение профиля и заказа распределялось между репликами с переменным отставанием.
Рассматривались три варианта. Постоянное чтение с основной базы быстро устраняло несогласованность, но создавало лишнюю нагрузку. Полностью синхронная репликация давала более сильную гарантию, однако увеличивала задержку оформления и связывала успешность записи с доступностью нескольких узлов. Простая задержка перед повторным чтением была ненадёжной, потому что отставание не является постоянной величиной.
Выбрали маршрутизацию чтений конкретного пользователя на основную базу после изменения заказа, а для обычных независимых чтений оставили реплики. Это устранило stale-after-write для критичного пользовательского сценария, сохранило масштабирование массовых чтений и сделало компромисс явным: часть трафика после записи стала дороже для основной базы.
Нет, если маршрутизация не гарантирует попадание на ту же реплику или если пользователь делает запросы через разные сервисы. Даже одна и та же реплика может ещё не применить запись, а разные реплики могут иметь разное отставание. Надёжнее использовать основную базу, отслеживать требуемую позицию репликации или применять согласованный механизм выбора реплики.
Не обязательно. Синхронная фиксация может гарантировать сохранение записи на нескольких узлах, но приложение всё равно может читать из узла или слоя кэша, который не предоставляет требуемую гарантию видимости. Нужно отдельно определить, какая гарантия нужна чтению, и обеспечить её маршрутизацией, ожиданием соответствующей версии или запретом неподходящего источника данных.
Нет. Дополнительные реплики повышают потенциальную пропускную способность чтения, но не устраняют задержку доставки изменений. Более того, они увеличивают объём репликационного трафика и число узлов, которые могут иметь разное состояние. Масштабирование реплик полезно только вместе с явным выбором гарантии свежести и контролем их отставания.