Распределённые системы
Кворумы: соберите хранилище с tunable consistency
Прочитать, что R + W > N принуждает к пересечению — не то же, что увидеть, как устаревшее чтение появляется в тот же миг, когда вы настраиваете ниже. Соберите небольшое реплицированное хранилище с R и W как ручками, затем заставьте гарантию — и каждый способ её сломать — происходить по требованию, с доказательствами.
Превратите инвариант пересечения в нечто воспроизводимое: реализуйте QUORUM-чтения и записи поверх N=3 симулированных реплик, докажите, что R + W > N даёт последнюю запись, затем намеренно вызовите потерю записи при W=1 и устаревшее чтение при sloppy quorum и зафиксируйте оба.
Соберите минимальное N=3 реплицированное key-value хранилище с пооперационно настраиваемыми R и W и подготовьте отчёт по тестам, эмпирически демонстрирующий гарантию пересечения R + W > N плюс два её тихих режима сбоя — потерю записи при W=1 и устаревшее чтение при sloppy quorum.
- Автоматизированный набор тестов, где каждый сценарий (пересечение-держится, потеря-записи-W=1, суб-пересекающийся-дрейф, устаревшее-чтение-sloppy, сходимость-handoff) — это именованный воспроизводимый тест, проверяющий точную возвращённую версию, а не ручная демонстрация.
- Краткая таблица отчёта: для каждой испробованной пары (R, W) укажите R + W, выполнено ли R + W > 3 и наблюдаемый результат (последняя / возможно-устаревшая / потеряна), сопоставляя теорию с наблюдением.
- Тест потери записи при W=1 надёжно воспроизводит потерю подтверждённой записи, доказывая, что сбой — следствие конфигурации, а не бага вашего хранилища.
- Параграф-вывод, объясняющий для каждого сценария сбоя, какая гарантия была потеряна, и точную арифметику (R + W против N) или смену состава (держатель hint вне множества чтения), вызвавшую это.
- Добавьте read repair: когда QUORUM-чтение видит расходящиеся версии, протолкните новейшую устаревшим репликам inline, и добавьте тест, показывающий, что следующее чтение того же ключа согласованно даже при R=1.
- Добавьте зонд латентности QUORUM-чтения: сделайте одну реплику медленной и покажите, что латентность QUORUM (R=2) чтения отслеживает вторую по скорости реплику, затем реализуйте request hedging (дубликат после задержки, берём первый) и покажите падение p99.
- Добавьте конкурентных писателей в один ключ при W=2 и покажите, что пересечение их НЕ упорядочивает — оба 'успешны' и вы получаете sibling-версии / last-write-wins — иллюстрируя, что пересечение гарантирует видимость, а не сериализацию.
- Сопоставьте свои ручки с реальным хранилищем: напишите эквивалентные уровни согласованности Cassandra (ONE / QUORUM / ALL) или флаги ConsistentRead DynamoDB для каждого сценария и отметьте, где управляемые дефолты скрыли бы баг.
Это эксперимент, превращающий инвариант пересечения из формулы в интуицию: реализуйте N=3 с настраиваемыми R и W, увидьте, как R + W > N надёжно отдаёт последнюю запись при любом отказе одного узла, затем настройте ниже и увидьте, как тихие сбои появляются по команде — ack при W=1, потерянный, когда его единственная реплика умирает, суб-пересекающееся чтение, выбирающее отставшую реплику, и sloppy-quorum запись, прячущаяся на держателе hint вне множества чтения, пока hinted handoff её не сведёт. Собрав это однажды, с арифметикой, сопоставленной наблюдаемому результату, вы становитесь инженером, который выбирает R и W осознанно, а не обнаруживает разрыв через тикет про устаревшие данные в 3 часа ночи.