В кластере временно недоступна одна реплика, но запись должна быть принята без ожидания её восстановления. Какой механизм описывает этот фрагмент?
write(key, value):
for replica in replicas:
if send(replica, key, value) == TIMEOUT:
pending.append((replica, key, value))
return ACCEPTED
retry_worker:
item = pending.take()
send(item.replica, item.key, item.value)
Это отложенная передача записи, обычно называемая hinted handoff. Если целевая реплика временно недоступна, другая доступная сторона сохраняет запись вместе с указанием её настоящего получателя, а после восстановления пересылает данные.
Механизм повышает доступность записи, но не обеспечивает немедленную согласованность: до успешной доставки реплики могут содержать разные версии.
Подход появился как практическое решение для высокодоступных распределённых хранилищ, работающих при временных отказах узлов и сетевых проблемах. Требовалось не блокировать запись только потому, что одна из реплик недоступна.
Это отражает компромисс между доступностью и согласованностью: система принимает запись сейчас, а восстановление полного набора реплик выполняет позже. Такой подход особенно полезен в системах с асинхронной репликацией, где кратковременная рассогласованность допустима.
Пусть данные должны храниться на трёх репликах, но одна из них временно не отвечает. Если координатор будет ждать её восстановления, запись станет недоступной даже при исправных остальных узлах.
Если же просто считать операцию завершённой после записи на доступные узлы, система должна где-то сохранить информацию о пропущенной реплике. Иначе после её восстановления будет неясно, какие записи нужно доставить.
При недоступности целевой реплики доступный узел временно сохраняет запись с метаданными: идентификатором настоящего получателя, ключом, версией или диапазоном журнала и сроком хранения. После восстановления реплики фоновый процесс пересылает накопленные данные.
Для корректности повторная доставка должна быть идемпотентной. Реплика должна уметь принять одну и ту же запись несколько раз без порождения лишнего эффекта; обычно это достигается сравнением версий, условной записью или использованием уникального идентификатора операции.
Нужно корректно обрабатывать удаления. Если сохранить только обновления, восстановленная реплика может вернуть уже удалённый объект. Поэтому применяют tombstone — маркер удаления, который хранится достаточно долго, чтобы опередить возможную старую запись.
Отложенные записи должны храниться надёжно. Если узел, временно заменивший целевую реплику, тоже потеряет данные, запись может быть утрачена. Поэтому используют журналирование, резервные копии или несколько мест хранения подсказок.
Этот механизм не равен строгой репликации. Он не гарантирует, что чтение с любой реплики сразу увидит последнюю запись, и не заменяет согласованный протокол выбора версии. При конфликте нужны версии, причинный контекст или заранее определённая стратегия разрешения.
На практике важно ограничивать срок жизни отложенных данных и контролировать их объём. Длительный отказ реплики может привести к переполнению локального хранилища; после превышения порога система может потребовать полной синхронизации по снимку или журналу.
Фрагмент возвращает ACCEPTED даже при тайм-ауте целевой реплики. Это корректно только при выбранной политике записи, допускающей временную недоступность части реплик. При строгом кворуме такая операция должна завершиться ошибкой, если подтверждений недостаточно.
В геораспределённом каталоге товаров одна реплика в регионе стала недоступна из-за сетевого сбоя. Вариант с ожиданием восстановления сохранял строгую гарантию наличия всех копий, но увеличивал задержку и делал регион записи недоступным.
Вариант с немедленным подтверждением без сохранения сведений о пропущенной реплике был быстрее, но после восстановления узел мог остаться устаревшим до полной проверки всех данных. Полная перестройка реплики надёжна, однако создаёт значительную нагрузку и увеличивает окно рассогласования.
Выбрали hinted handoff с записью подсказок в устойчивый журнал, повторной доставкой по версиям и последующей антиэнтропийной сверкой. Это позволило принимать записи во время кратковременного сбоя, а после восстановления автоматически догнать реплику без полной перестройки.
Чем hinted handoff отличается от sloppy quorum?
Hinted handoff — это механизм временного хранения данных для недоступной целевой реплики. Sloppy quorum — политика выбора временных узлов, которым разрешено принять запись вместо узлов из исходного набора реплик. На практике они часто используются вместе, но это разные понятия: первое отвечает за последующую доставку, второе — за выбор получателей записи.
Что произойдёт, если временный хранитель потеряет подсказку?
Отложенная доставка не является магической гарантией сохранности. При потере временного хранителя запись может остаться только на части реплик или исчезнуть, если политика подтверждения не обеспечивала достаточную долговечность. Поэтому подсказки журналируют, реплицируют или компенсируют регулярной антиэнтропийной синхронизацией.
Почему нельзя удалить подсказку сразу после первой успешной отправки?
Ответ на отправку может означать только принятие данных в память или журнал, но не их окончательную фиксацию. Подсказку удаляют после подтверждения требуемого уровня долговечности на целевой реплике; иначе сбой сразу после подтверждения снова создаст рассогласование. Кроме того, повторная доставка должна быть безопасной, поскольку тайм-аут не позволяет надёжно отличить потерянную отправку от уже применённой.