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