Paxos 是 Leslie Lamport 1990 年提出的基於消息傳遞的一致性算法，解決分布式系統如何就某個值（決議）達成一致。工程上可實現多副本一致性、分布式鎖、名字服務、序列號分配等。本文從 Basic Paxos 兩階段流程切入，深入 Multi-Paxos 領導者優化、選主租約、日誌恢復、Confirm 機制、Group Commit 等工程關鍵點，並通過 Q&A 解析與 2PC、傳統主備、數據庫復制的關聯差異。
| 角色/術語 | 說明 |
|---|---|
| Proposer | 提議發起者，處理客戶端請求，向集群廣播提議 |
| Acceptor | 提議批准者，投票決定值是否通過，持久化狀態 |
| Replica | 節點/副本，通常同時承擔 Proposer 與 Acceptor |
| ProposalId | 全局遞增編號，編號高者優先級高（常用 timestamp + serverId） |
| Paxos Instance | 針對單一值達成一致的完整過程（如同一 logIndex） |
| acceptedProposal/Value | 當前 Instance 已接受的最高提議編號及其值 |
| minProposal | Acceptor 承諾不再接受的最小提議編號，持續更新 |
Phase 1 - Prepare（準備階段）
PREPARE(n)。n > minProposal，更新 minProposal = n，回應 (acceptedProposal, acceptedValue)；否則忽略或拒絕。acceptedValue，必須採用編號最大者的值（保證安全性），然後進入 Phase 2；若無，可自由提議任意值。Phase 2 - Accept（提議階段）
ACCEPT(n, value) 至所有 Acceptor。n >= minProposal，持久化 acceptedProposal=n, acceptedValue=value，回應成功；否則回應當前 minProposal 導致 Proposer 重試。minProposal → 跳回步驟 1 重試。併發多 Proposer 交替發起 Prepare，導致雙方不斷搶佔過半數、互相打斷 Accept，陷入無限重試（LiveLock）。
Multi-Paxos 核心優化：引入 Leader (Distinguished Proposer)。
ProposalId，跳過 Phase 1 直接進入 Accept。本質是一次 Paxos 實例，決議值為「誰是 Leader」。為防止頻繁切主：
StartWorking 日誌，過半數持久化確認身份。logId，取過半數響應中的最大值作為恢復終點（包含所有已提交日誌，可能含未提交）。logId 執行 Paxos 協議（跳過已 Confirm 的）。Confirm 通知 Follower 寫入確認標記。新主啟動時掃描本地 Confirm 標記，跳過對應 Paxos 輪次，大幅縮短恢復時間。將多條日誌打包為一個 Batch 執行單次 Paxos 實例，要麼全成功要麼全失敗。以 RTT 換吞吐，類比 MySQL Binlog Group Commit。
| 異常類型 | 影響 | 處理策略 |
|---|---|---|
| Leader 進程/OS Crash | 心跳超時觸發重選 | 重啟時間 > 租約超時即視為失效 |
| 網絡分區/抖動 | 可能誤觸發選主 | 心跳超時設較大值；節點部署跨 IDC 保證過半數存活 |
| 磁盤故障 | 節點丟失所有日誌/狀態 | 視為新節點，需先追趕 Leader 觀察一輪完整 Paxos 才恢復 Promise 能力 |
| Follower 異常 | 不影響對外服務（過半數仍可用） | 重啟後追趕 Leader 至最新日誌 |
