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