Zookeeper Paxos演算法 一致性協議
前言
Paxos 一致性協議可以說是一致性協議研究的起點，也以難以理解聞名。其實協議本身並沒有多難理解，它的難理解性主要體現在：為何如此設計協議以及如何證明其正確性。本文嘗試通過流程圖來說明協議的內容以及基本應用過程，不涉及如何證明其正確性。
基本概念
Paxos 可以分為兩種：
- Single-Decree Paxos：決策單個 Value
- Multi-Paxos：連續決策多個 Value，並且保證每個節點上的順序完全一致，多 Paxos 往往是同事執行多個單 Paxos 協議共同執行的結果。
本文只關注單 Paxos 的原理，理解了單 Paxos，多 Paxos 也就不難理解了。
Paxos 協議中的三種角色
- 倡議者（Proposer）：倡議者可以提出提議（數值或者操作命令）以供投票表決
- 接受者（Acceptor）：接受者可以對倡議者提出的提議進行投票表決，提議有超半數的接受者投票即被選中
- 學習者（Learner）：學習者無投票權，只是從接受者那裡獲知哪個提議被選中
在協議中，每個節點可以同時扮演以上多個角色。
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演算法
原設計師的最先設計方案：
上圖的圖解，缺了一部分同步的操作，當然不是作者畫錯了，而是我們的分散式發現服務的問題，當一個節點不可用，那麼發起議案的時候，節點不可用，那麼提交議案成功後，也不會去再同步此節點，因為不可用。
交叉分散式事務
下圖將解說交叉分散式同步問題，下圖將採用的另一個收費課程的圖解：更復雜！！！！
模擬場景：戰略會議 交叉分散式事務
制定作戰計劃，兩位作戰計劃的制定者，分別制定一個計劃，上面的進攻時間改為進攻目標更妥當
三位將軍作為計劃的執行者。
開始：
1：參謀1 制定作戰目標成功，傳送給三個將軍。但是將軍3與他有意見，拒絕他的意見，此時的將軍1，將軍2，覺得作戰目標可行。同意
2：在參謀1還沒做表決的時候，參謀2，將作戰目標做完，分別發給三位將軍，這時將軍1跟參謀2有意見，不接受他的作戰目標。其他兩個將軍覺得作戰目標可行，同意
3：這是參謀1 舉行表決，超過半數即可行。將軍2 將軍1 做表決，但是將軍2接受了新的作戰計劃，此時不再能執行作戰計劃1了，所以參謀一的作戰計劃未通過
4：此時參謀2開始做作戰計劃的表決，因為將軍2 將軍3 同意，因此此計劃通過。這時其實意味這分散式事務的成功，資料一致性處理成功
5：此時參謀1 又做了一個作戰計劃，3 發給將軍1，將軍2，此時將軍1，2返回他們手裡的作戰計劃，看是否領先作戰計劃3。
6：參謀1發現將軍1，將軍2 的作戰計劃已執行，可以表決自己的作戰計劃，則提交表決
7：將軍1 將軍2 表決通過參謀1的作戰計劃3
哈哈，懵了沒有，其實這模擬的是：
如淘寶交易，同一時間兩個會員購買同一個商會，第一個會員需要去修改淘寶的分散式系統的商會剩餘數量，此時第二位同時間消費的會員也要來修改資料。時間在0.00毫秒間產生。交叉型的分散式事務處理出現在超大型併發系統中。這時兩個會員會出現爭奪誰先去修改庫存的操作。看得懂的行家可能會說，在參謀2提交計劃成功的時候，參謀1又提交議案，就造成了死鎖了。Paxos演算法在提交失敗後，睡眠1毫秒參謀2的提議就表決通過了。當然演算法內還有更深層次的實現，無法得知：，目前 google facebookIBM 都有自己的演算法實現，可是都沒有公開原始碼，zookeeper的實現原始碼好像說也很晦澀。但是演算法內部用佇列或者一些簡單的處理機制就可以避免上面這種彼此死鎖的方式。