Распределённые системы
Кворумы: тест с выбором ответа
Суть Синтез всего раздела про quorum в формате с выбором ответа: арифметика R + W > N, tunable consistency, sloppy quorum и hinted handoff, и тихие производственные сбои.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов через весь раздел. Каждый — это решение, которое вы принимаете, когда подбираете размер кластера или разбираете тикет про устаревшее чтение: не определение для пересказа, а арифметика R, W и N в условиях реальных отказов.
Цель
Убедитесь, что выводите гарантию пересечения из R + W > N, размещаете конфигурацию на треугольнике consistency/availability/latency и точно предсказываете, какую именно гарантию sloppy quorum теряет во время partition.
Викторина
Completed
Кластер с RF=5. Нужно, чтобы каждое чтение гарантированно видело последнюю успешную запись, при этом переживая как можно больше отказов узлов. Какая минимальная пара (R, W) даёт строгую согласованность, и сколько одновременных отказов узлов она переживает на каждом пути?
Heads-up 5 не строго больше 5. R + W должно быть > N, а не >= N. При R=2, W=3 чтение может выбрать 2 реплики, которые обе пропустили запись, и вернуть устаревшие данные.
Heads-up Сумма 6 > 5 действительно даёт пересечение, но W=5 означает, что один упавший узел проваливает каждую запись — это 0 переживаемых отказов записи, противоположность 'как можно больше'. QUORUM R=3,W=3 переживает 2 на каждом пути.
Heads-up Сумма 6 > 5 даёт пересечение, но R=5 означает, что один медленный или упавший узел блокирует каждое чтение (0 переживаемых отказов чтения), а W=1 рискует потерять ack, если единственный узел умрёт. QUORUM балансирует оба пути.
Викторина
Completed
Платёжный сервис на RF=3 пишет с W=1 'ради латентности'. Ночью узел подтверждает обновление реквизитов выплаты, затем падает при деплое до репликации. Следующее чтение отдаёт старый номер счёта. Что на самом деле пошло не так?
Heads-up Репликация отработала ровно так, как сконфигурировано. W=1 значит 'ack после одной реплики' — рантайм никогда не обещал, что остальные две получат данные до ack. Потеря — выбор конфигурации, а не дефект кода.
Heads-up R=3 при W=1 даёт сумму 4 > 3 и поймал бы выжившую копию — но здесь единственная копия умерла, так что даже R=3 ничего не найдёт. Корень — это W=1 и durability, а не настройка чтения.
Heads-up Деплой — лишь один из триггеров. Любой крэш, GC-пауза или отказ диска в окне между ack при W=1 и репликацией теряет запись. W=1 превращает отказ одной реплики в событие потери данных.
Викторина
Completed
Тот же кластер RF=3, настроен на строгий W=2, R=2. Во время сетевого partition запись через sloppy quorum попадает на узлы-заместители, держащие hint, а строгое чтение с домашних реплик возвращает устаревшие данные. Почему W=2, R=2 здесь не спасает?
Heads-up Он сохраняет ваш счётчик W — два узла всё равно подтверждают. Меняется лишь то, КАКИЕ узлы могут его удовлетворить: здоровые заместители через hinted handoff, а не назначенные реплики. Счётчики те же, состав другой.
Heads-up Read repair может протолкнуть только ту новую версию, которую видит. Во время partition последняя запись лежит на держателях hint, к которым чтение не обращается, поэтому при чтении нет более свежей копии для починки.
Heads-up R=3 читает все три домашние реплики, но hinted-запись лежит на узлах-заместителях вне этого множества, поэтому R=3 всё равно её пропустит в разгар partition. Дыра — это приостановленное пересечение, а не значение R.
Викторина
Completed
Команда утверждает: 'R=1, W=2 при N=3 — нормально, ведь запись уже на большинстве'. Что неверно в этом рассуждении?
Heads-up Мажоритарная запись гарантирует, что значение на 2 из 3, но R=1 может прочитать оставшуюся 1, которая его пропустила. Согласованность даёт принудительное пересечение (R + W > N), а не сам факт записи на большинство.
Heads-up W=2 — это ровно QUORUM и оно нормально — в паре с R=2. Изъян в R=1, который роняет сумму до 3 и ломает пересечение. Чинить надо чтение, а не запись.
Heads-up Нет гарантии, что координатор держит ключ или последнюю версию; координаторы маршрутизируют, они не обязательно реплики. Пересечение должно обеспечиваться арифметикой R + W > N, а не везением маршрутизации.
Викторина
Completed
При RF=3 QUORUM-чтение (R=2) показывает p99 намного хуже p50, хотя латентности отдельных узлов выглядят здоровыми. Каков механизм и какая мера борется с ним напрямую?
Heads-up Латентность определяется ожиданием самой медленной нужной реплики, а не CPU координатора. Лишние ядра ничего не дают чтению, заблокированному на реплике в GC-паузе; помогает hedging или снижение R.
Heads-up Read repair срабатывает, только когда реплики расходятся, и обычно дёшев. Структурный драйвер p99 — это 'жди 2-ю по скорости из 3', свойство хвоста латентности самого R.
Heads-up R=1 действительно убирает ожидание, но при N=3 с W=2 роняет R + W до 3 и ломает гарантию пересечения. Hedging срезает хвост БЕЗ жертвы согласованностью; снижение R меняет корректность на латентность.
Викторина
Completed
Пересечение (R + W > N) гарантирует, что QUORUM-чтение видит последнюю зафиксированную запись. Чего из перечисленного оно НЕ гарантирует?
Heads-up Это как раз то, что пересечение ДАЁТ: множества чтения и записи делят узел с последним значением. А вот упорядочивания конкурентных записей quorum не даёт.
Heads-up QUORUM действительно даёт переживание отказа одного узла на обоих путях — поэтому он лучше ALL. Отсутствующая гарантия — сериализация конкурентных записей одного ключа.
Heads-up Tunable consistency и правда позволяет задавать R и W на запрос. Но пересечение НЕ даёт упорядочивания конкурентных записей — видимость это не сериализация.
Итог
Сквозная линия — одно неравенство: R + W > N принуждает множества чтения и записи пересечься, поэтому QUORUM-чтение видит последнюю зафиксированную запись — и в момент, когда вы настраиваете ниже (R=1,W=2 в сумме N или W=1), устаревшие чтения и потерянные записи становятся законными, а не багами. QUORUM (W=2,R=2 при N=3; W=3,R=3 при N=5) — производственный дефолт, потому что держит пересечение, переживая один (или два при N=5) упавший узел на обоих путях, в отличие от ALL. R — ещё и ручка p99: QUORUM-чтение ждёт самую медленную нужную реплику, отсюда hedging. А sloppy quorum покупает доступность записи во время partition, паркуя записи на держателях hint вне множества чтения, приостанавливая пересечение ровно тогда, когда узел упал; read repair и anti-entropy на деревьях Меркла сходят данные потом — обычно.