Кворумы: тест с выбором ответа
Синтез всего раздела про quorum в формате с выбором ответа: арифметика R + W > N, tunable consistency, sloppy quorum и hinted handoff, и тихие производственные сбои.
Шесть вопросов через весь раздел. Каждый — это решение, которое вы принимаете, когда подбираете размер кластера или разбираете тикет про устаревшее чтение: не определение для пересказа, а арифметика R, W и N в условиях реальных отказов.
Убедитесь, что выводите гарантию пересечения из R + W > N, размещаете конфигурацию на треугольнике consistency/availability/latency и точно предсказываете, какую именно гарантию sloppy quorum теряет во время partition.
Кластер с RF=5. Нужно, чтобы каждое чтение гарантированно видело последнюю успешную запись, при этом переживая как можно больше отказов узлов. Какая минимальная пара (R, W) даёт строгую согласованность, и сколько одновременных отказов узлов она переживает на каждом пути?
Платёжный сервис на RF=3 пишет с W=1 'ради латентности'. Ночью узел подтверждает обновление реквизитов выплаты, затем падает при деплое до репликации. Следующее чтение отдаёт старый номер счёта. Что на самом деле пошло не так?
Тот же кластер RF=3, настроен на строгий W=2, R=2. Во время сетевого partition запись через sloppy quorum попадает на узлы-заместители, держащие hint, а строгое чтение с домашних реплик возвращает устаревшие данные. Почему W=2, R=2 здесь не спасает?
Команда утверждает: 'R=1, W=2 при N=3 — нормально, ведь запись уже на большинстве'. Что неверно в этом рассуждении?
При RF=3 QUORUM-чтение (R=2) показывает p99 намного хуже p50, хотя латентности отдельных узлов выглядят здоровыми. Каков механизм и какая мера борется с ним напрямую?
Пересечение (R + W > N) гарантирует, что QUORUM-чтение видит последнюю зафиксированную запись. Чего из перечисленного оно НЕ гарантирует?
Сквозная линия — одно неравенство: 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 на деревьях Меркла сходят данные потом — обычно. Теперь, когда будете смотреть конфиг уровней согласованности в пулл-реквесте, первым делом посчитаете R + W > N — и будете знать, какой вопрос задать, если цифры не сходятся.
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.