Распределённые системы
Выбор лидера: собери отсечённого единственного писателя
Читать про split-brain — не то же самое, что смотреть, как два твоих собственных процесса портят один файл. Собери писателя с выбором лидера на реальном лок-сервисе, намеренно вгони его в split-brain внедрённой паузой, а затем закрой окно fencing-токеном, который навязывает ресурс — с доказательством на каждом шаге.
Преврати аргумент безопасности юнита в воспроизводимый эксперимент: выбери лидера через lease, воспроизведи устаревшую запись через внедрённую паузу и докажи, что монотонный fencing-токен, проверяемый у ресурса, делает ту же атаку пустышкой.
Собери небольшую задачу с выбором лидера, которая пишет в общий ресурс, воспроизведи split-brain с устаревшей записью, внедрив паузу длиннее lease, затем добавь fencing-токен, навязанный ресурсом, и докажи, что та же устаревшая запись теперь отвергается — всё подкреплено логами.
- Пара логов до/после: прогон без fencing показывает двух писателей и испорченное или устаревшее итоговое состояние; прогон с fencing показывает устаревшую запись leaderA отвергнутой по меньшему токену, тогда как запись leaderB остаётся.
- Проверка fencing живёт у ресурса (побеждает наибольший токен), а не только в лок-сервисе — продемонстрировано показом, что запись, обходящая лок-сервис, но несущая устаревший токен, всё равно отвергается.
- Измеренное число failover (от начала паузы до первой записи нового лидера) плюс одно предложение о том, почему сокращение lease TTL ускоряет failover, но увеличивает ложные выселения здоровых-но-медленных лидеров.
- Короткий разбор, называющий, какие двое часов охватывает lease, почему самопроверка или колбэк keep-alive не смогли бы предотвратить устаревшую запись и почему проверка токена на стороне ресурса смогла.
- Воспроизведи ДРУГУЮ причину split-brain: раздели лок-кластер partition'ом (или заблокируй сеть одного воркера) и покажи, что корректный протокол на кворуме запрещает стороне-меньшинству выбирать, в отличие от наивного однонодного лока.
- Добавь on-call runbook: как обнаружить split-brain в логах (перекрывающиеся term'ы лидеров, всплески отвергнутых токенов), как подтвердить, что ресурс навязывает fencing, и безопасный порядок мер.
- Смени бэкенд лока (например, etcd на ZooKeeper) и покажи, что логика fencing приложения не меняется, потому что навязывание токена живёт у ресурса, а не у лок-сервиса.
- Добавь метрику и алерт: эмитируй счётчик отсечённых (отвергнутых по токену) записей и алерти, когда он не ноль, поскольку любая отсечённая запись означает, что только что произошло и было сдержано реальное событие split-brain.
Это петля, которую ты запустишь, когда прилетит инцидент координации: подними реальный выбор лидера, воспроизведи сбой (паузу, которая переживает lease) вместо споров о нём и докажи фикс логами, а не уверенностью. Прогон без fencing показывает, почему лока или lease одного мало против приостановленного писателя; прогон с fencing показывает, почему монотонный токен, навязанный у ресурса, помогает. Когда ты сам увидишь, как два твоих процесса отсекаются друг от друга на границе хранилища, «выбирай ради liveness, отсекай ради safety» перестаёт быть лозунгом и становится мышечной памятью.