Paxos 一致性協議可以說是一致性協議研究的起點，也以難以理解聞名。其實協議本身並沒有多難理解，它的難理解性主要體現在：為何如此設計協議以及如何證明其正確性。本文嘗試通過流程圖來說明協議的內容以及基本應用過程，不涉及如何證明其正確性。
基本概念
Paxos 可以分為兩種：
- Single-Decree Paxos：決策單個 Value
- Multi-Paxos：連續決策多個 Value，並且保證每個節點上的順序完全一致，多 Paxos 往往是同事執行多個單 Paxos 協議共同執行的結果。
本文只關注單 Paxos 的原理，理解了單 Paxos，多 Paxos 也就不難理解了。
Paxos 協議中的三種角色
- 倡議者（Proposer）：倡議者可以提出提議（數值或者操作命令）以供投票表決
- 接受者（Acceptor）：接受者可以對倡議者提出的提議進行投票表決，提議有超半數的接受者投票即被選中
- 學習者（Learner）：學習者無投票權，只是從接受者那裡獲知哪個提議被選中
在協議中，每個節點可以同時扮演以上多個角色。
Paxos 的特點
- 一個或多個節點可以提出提議
- 系統必須針對所有提案中的某個提案達成一致（超過半數的接受者選中）
- 最多隻能對一個確定的提議達成一致
- 只要超半數的節點存活且可互相通訊，整個系統一定能達成一致狀態，即選擇一個確定的提議
協議圖示
Paxos
通過上面的流程，如果有多個節點同時提出各自的提議，Paxos 就可以保證從中選出一個唯一確定的值，保證分散式系統的一致性。
例項
下面我們通過例子來理解 Paxos 的實際應用過程。
假設現在有五個節點的分散式系統，此時 A 節點打算提議 X 值，E 節點打算提議 Y 值，其他節點沒有提議。
假設現在 A 節點廣播它的提議（也會傳送給自己），由於網路延遲的原因，只有 A，B，C 節點收到了。注意即使 A，E 節點的提議同時到達某個節點，它也必然有個先後處理的順序，這裡的“同時”不是真正意義上的“同時”。
A，B，C接收提議之後，由於這是第一個它們接收到的提議，acceptedProposal 和 acceptedValue 都為空。
由於 A 節點已經收到超半數的節點響應，且返回的 acceptedValue 都為空，也就是說它可以用 X 作為提議的值來發生 Accept 請求，A，B，C接收到請求之後，將 acceptedValue 更新為 X。
A，B，C 會發生 minProposal 給 A，A 檢查發現沒有大於 1 的 minProposal 出現，此時 X 已經被選中。等等，我們是不是忘了D，E節點？它們的 acceptedValue 並不是 X，系統還處於不一致狀態。至此，Paxos 過程還沒有結束，我們繼續看。
此時 E 節點選擇 Proposal ID 為 2 傳送 Prepare 請求，結果就和上面不一樣了，因為 C 節點已經接受了 A 節點的提議，它不會三心二意，所以就告訴 E 節點它的選擇，E 節點也很紳士，既然 C 選擇了 A 的提議，那我也選它吧。於是，E 發起 Accept 請求，使用 X 作為提議值，至此，整個分散式系統達成了一致，大家都選擇了 X。
上面是 Paxos 的一個簡單應用過程，其他複雜的場景也可以根據流程圖慢慢推導，這裡只是拋磚引玉。