После записи в распределённое хранилище клиент должен сразу прочитать подтверждённое значение даже при отказе узла. Какой механизм согласования чтения и записи это обеспечивает?
Это обеспечивает кворумное чтение и запись: запись считается принятой после подтверждения от W реплик, а чтение обращается минимум к R репликам. При количестве реплик N условие R + W > N гарантирует пересечение множеств реплик, поэтому чтение видит хотя бы одну реплику, участвовавшую в подтверждённой записи.
Гарантия действует при корректном выборе реплик, сохранении версий и отсутствии обхода кворумного протокола. Сам по себе кворум не всегда означает полную линейризуемость: для неё могут потребоваться лидер, консенсус или дополнительная координация.
В централизованном хранилище чтение после записи обычно обращается к единственному источнику состояния. После репликации данные стали доступнее при отказах, но возникла проблема: разные реплики могут обновляться с задержкой.
Кворумный подход использует пересечение наборов реплик вместо ожидания синхронного обновления всех узлов. Он позволяет выбирать компромисс между задержкой, доступностью и строгостью согласованности.
Пусть данные хранятся на N репликах. Если запись подтверждается только одной репликой, а следующее чтение попадает на другую, клиент может увидеть старое значение, хотя запись уже считалась успешной.
Слишком строгий протокол, требующий ответа от всех реплик, уменьшает доступность: отказ одного узла блокирует операции. Слишком слабый протокол снижает задержку, но допускает чтение устаревших данных и усложняет разрешение конфликтов.
При записи система отправляет значение нескольким репликам и ждёт подтверждения от W из них. При чтении она запрашивает R реплик, сравнивает версии или логические метки и выбирает наиболее новое согласованное значение.
Ключевое условие — R + W > N. Тогда множество реплик, подтвердивших запись, и множество реплик, опрошенных при чтении, не могут быть полностью разными. Например, при N = 3, W = 2 и R = 2 эти множества пересекаются минимум по одной реплике.
Кворум не исправляет конфликтующие записи автоматически. Система должна иметь правило разрешения конфликтов: версии, монотонные номера, временные метки с оговорёнными ограничениями или применение операций в определённом порядке.
Также важно различать кворумную согласованность и линейризуемость. Кворум может гарантировать обнаружение последней записи при подходящей модели чтения, но конкурентные операции, повторные попытки и смена владельца данных требуют дополнительной координации.
На практике доступность кворума зависит от отказов и сетевых разделений. При строгом кворуме операция может быть отклонена, если недоступно достаточное число реплик; это плата за более сильную гарантию чтения после записи.
В платформе заказов данные реплицируются на три узла. Требование бизнеса — после подтверждения изменения статуса заказа повторное чтение не должно возвращать предыдущий статус при отказе одного узла.
Вариант с W = 1 и R = 1 даёт минимальную задержку и высокую доступность, но не гарантирует нужное поведение. Запись может попасть на один узел, а чтение — на отставшую реплику.
Вариант с ожиданием всех трёх реплик лучше защищает от рассогласования, но делает запись недоступной при отказе любого узла. Он также увеличивает задержку.
Выбран кворум W = 2 и R = 2 с хранением версии записи. При отказе одного узла остаются два доступных узла, а множества участников записи и чтения пересекаются. Для операций, которым нужна строгая линейризуемость, поверх этого выбран отдельный протокол с лидером и подтверждением упорядочивания операций.
R + W > N для любой гарантии согласованности?Нет. Оно обеспечивает пересечение наборов реплик, но итоговая гарантия зависит от того, как система выбирает версии, обрабатывает конкурентные записи и маршрутизирует чтения. Для линейризуемости требуется, чтобы операции имели единый порядок, а не только общую реплику.
Гарантия теряется, если выбранная реплика не обязана быть участником кворума или не подтверждает актуальность своего состояния. Маршрутизатор должен либо обращаться к достаточному числу реплик, либо направлять чтение к лидеру или реплике, которая гарантированно догоняет подтверждённую запись.
При разделении сети часть реплик может стать недоступной. Если оставшаяся часть не содержит кворум, система должна выбирать между отказом операции и ослаблением гарантии. Если разрешить запись в изолированной меньшинству, после восстановления могут возникнуть конфликтующие версии, которые придётся разрешать отдельно.