Выбор лидера: тест с выбором ответа
Тест с выбором на синтез по всему юниту leader election — term'ы и таймауты, lease против часов, split-brain и fencing-токен, который обязан проверять ресурс.
Шесть вопросов поперёк всего юнита. Каждый отражает решение, которое ты принимаешь в реальном инциденте — не определение для заучивания, а аргумент безопасности, который надо защитить, когда лидер встаёт на паузу, partition заживает или два узла одновременно претендуют на корону.
Убедись, что связываешь, зачем вообще выбирать лидера, как Raft выбирает его безопасно, почему lease — это утверждение о часах, которым нельзя верить, и почему только проверяемый ресурсом fencing-токен закрывает окно split-brain.
Лидер держит 10-секундный lease и пишет в объектное хранилище; ты наблюдал многосекундные GC-паузы. Какая мера действительно закрывает окно устаревшей записи, а не просто сужает его?
Почему Raft выбирает election timeout каждого фолловера случайно из диапазона примерно 150–300 мс вместо одного фиксированного значения?
Сеньор говорит: «lease не ограничивает, сколько приостановленный лидер будет верить, что лидирует». В чём точная причина и каково последствие?
Команда добавила fencing-токены: лок-сервис раздаёт строго возрастающие числа, а лидер штампует ими каждую запись. Инциденты продолжаются. Какой пробел наиболее вероятен?
Кластер из 5 узлов разделён сетевым partition на 3-2. Как ведёт себя корректный протокол выбора на кворуме и почему?
Тебе нужно «запустить этот cron ровно на одном хосте», и ты берёшь распределённый лок. Ревьюер предупреждает, что лока одного для корректности мало. Чего не хватает?
Сквозная линия юнита — одно дерево решений: выбери единственного лидера, чтобы сериализовать записи (Raft использует term’ы плюс рандомизированные таймауты 150–300 мс, чтобы выбрать его безопасно), держи лидерство как lease, который координатор может истечь, — но никогда не верь, что приостановленный лидер знает, что потерял lease. Partition обрабатывается кворумом (лидирует только большинство); пауза обрабатывается монотонным fencing-токеном, который навязывает сам защищаемый ресурс. Теперь, когда будешь ревьюить дизайн распределённого лока, задай один вопрос прежде всего: проверяет ли защищаемый ресурс токен и отвергает ли записи с меньшим значением, чем наибольший виденный? Если нет — лок неполный, и никакой подкруткой TTL это не исправить.
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.