Распределённые системы
Raft: тест на свободное воспроизведение
Воспроизведение бьёт перечитывание. Для каждого промпта восстанови полный механизм по памяти — вслух или на бумаге — прежде чем открыть модельный ответ. Именно усилие припоминания закрепляет аргумент безопасности.
Восстанови стержень юнита, не подглядывая: аргумент безопасности через пересечение кворумов, что значит «закоммичено», почему правило голосования сохраняет историю, как линеаризуемые чтения избегают записи в лог и почему смена состава требует joint consensus.
- 01Почему требование majority quorum и для выборов, и для коммитов предотвращает split brain, и почему именно majority, а не любая группа фиксированного размера?
- 02Что значит «закоммичено» в Raft и почему одиночного fsync недостаточно?
- 03Как правило полноты лога в RequestVote сочетается с пересечением кворумов, давая Leader Completeness, и какова дополнительная оговорка про коммит текущего term?
- 04Сравни ReadIndex и lease reads для линеаризуемых чтений и назови условие корректности, делающее lease reads рискованными.
- 05Почему изменение состава кластера требует joint consensus и что именно обеспечивает joint-фаза?
- 06Каков минимально жизнеспособный дашборд Raft и на какую корневую причину указывает каждая метрика?
Если ты смог восстановить каждый ответ по памяти, ты держишь стержень юнита: majority quorum принуждает к пересечению, из-за которого закоммиченная (персистированная majority) запись переживает любую смену лидера; голос по полноте лога плюс это пересечение дают Leader Completeness, а правило коммита текущего term закрывает дыру figure-8; ReadIndex и lease reads обслуживают линеаризуемые чтения без записи в лог — lease reads меняют условие корректности по NTP на субмиллисекундную задержку; а joint consensus не даёт смене состава расколоть кластер. Следи за пятью метриками и помни, что реальные инциденты почти всегда сводятся к обойдённой смене состава, отключённому pre-vote или медленному диску.