Распределённые системы
Raft: собери и сломай кластер
Прочитать доказательство безопасности — не то же самое, что увидеть, как кластер усекает незакоммиченную запись, останавливает меньшинство при partition и переживает замену узла без потери записи. Подними небольшой Raft-кластер, прогони его через ровно те failure mode, что описывал юнит, и собери доказательства, что каждая гарантия держалась.
Преврати ментальную модель юнита в воспроизводимую лабораторию: реплицируй лог, спровоцируй выборы лидера, докажи, что закоммиченная запись выживает, а незакоммиченная отбрасывается, продемонстрируй CP-остановку при partition и выполни безопасную смену состава — каждый шаг подкреплён логами или метриками, а не утверждением.
Подними кластер из 3 (затем 5) узлов Raft — реальный (встроенный hashicorp/raft, etcd или реализация с нуля) либо детерминированный симулятор — и продемонстрируй, с собранными доказательствами, что он реплицирует лог, корректно избирает лидеров, сохраняет закоммиченные записи при падениях, останавливает сторону меньшинства при partition и безопасно меняет состав.
- Лог сценария или запись для каждого из: реплицированная запись применена одинаково на всех узлах; чистые выборы с новым term; незакоммиченная запись усечена после падения лидера; закоммиченная запись пережила то же падение; остановка меньшинства + прогресс большинства при partition.
- Доказательство — собранные логи или метрические панели — что term растёт монотонно, что commitIndex продвигается лишь когда matchIndex majority покрывает запись, и что никакие два узла никогда не применили разные команды на одном индексе.
- Транскрипт смены состава, показывающий переход кластера 3 в 5 по одному узлу за раз, с корректным обновлением размера quorum и числа допустимых отказов, без периода, когда могли бы существовать два непересекающихся majority.
- Одностраничный разбор, сопоставляющий каждое продемонстрированное поведение со свойством, которое его гарантирует: пересечение кворумов, Log Matching, Leader Completeness, правило коммита текущего term и CP-компромисс.
- Внеди fault медленного диска: задросселируй fsync лидера сверх интервала heartbeat и зафиксируй вызванное мигание выборов; затем покажи, что перенос WAL на быстрое хранилище (или подъём election timeout как временная мера) восстанавливает стабильность.
- Добавь snapshot'ы: компактируй лог после N записей, уведи follower'а в оффлайн достаточно надолго, чтобы лидер компактировал нужные ему записи, и покажи, как InstallSnapshot возвращает его в синхрон — включая конфигурацию состава внутри snapshot'а.
- Добавь pre-vote и воспроизведи помеху от возвращающегося узла с ним и без: покажи, как долго-партиционированный узел триггерит ненужные выборы без pre-vote и тихо отвергается с ним.
- Добавь ReadIndex или lease reads и измерь latency линеаризуемого чтения против наивного no-op-commit чтения при высоком отношении чтений к записям; для lease reads продемонстрируй failure mode по clock skew, намеренно сдвинув часы одного узла.
Это та лаборатория, что превращает доказательство в рефлексы. Когда ты сам увидел, как кластер усекает незакоммиченную запись, держит закоммиченную через то же падение, останавливает меньшинство при partition, пока большинство коммитит, и растит состав по одному узлу без окна split-brain — и всё подкреплено твоими собственными логами и метриками — аргумент безопасности перестаёт быть абстракцией. Сопоставь каждое поведение со свойством, которое его гарантирует, и ты будешь диагностировать production-инцидент (медленный диск, отключённый pre-vote, обойдённая смена состава) по метрикам за минуты, а не часы.