🗺️ このノートは 第5章「合意」のハブ です。
第5章 ── 合意
分散システムの心臓部です。「複数のノードが、故障があっても、1つの値に同意する」——これが合意（consensus）。リーダーは誰か、トランザクションはコミットか中止か、ログの次のエントリは何か。すべてが合意に帰着します。この章は、非同期では合意が不可能という衝撃的な定理（FLP）から始め、それでも実用的に合意を作る古典（2PC/3PC・Paxos）と、理解しやすさを設計目標にした現代の定番（Raft）、そして合意の入口であるリーダー選出までを扱います。
通底するのは「過半数（クォーラム）の重なりで、矛盾を構造的に防ぐ」という発想と、必ず**安全性（決して2つの値を確定しない）と活性（いつかは決まる）**を分けて語る姿勢です。
トピック一覧
- 合意問題とFLP不可能性 — 何が問題で、なぜ非同期では不可能か
- 2相コミット・3相コミット — アトミックコミットとブロッキング問題
- Paxos — 古典的合意の決定版とその難しさ
- Raft — 理解しやすさを設計したリーダーベース合意
- リーダー選出（Bully・Ring） — 合意の入口となる基本選出
この章の位置づけ
- 前提は 障害モデル（クラッシュ・オミッション・ビザンチン）・論理時計（Lamportタイムスタンプ）
- 合意は強一貫（線形化可能性と逐次一貫性）を作る道具。CAPでは CP 側（CAP定理）
- 合意でリーダーを選び、ログを複製すると次章 レプリケーション方式（同期／非同期・リーダー／リーダーレス） に繋がる