前言
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的實現原始碼好像說也很晦澀。但是演算法內部用佇列或者一些簡單的處理機制就可以避免上面這種彼此死鎖的方式。
關於zookeeper的討論
zookeeper作為分布式集群廣泛使用的應用程式協調服務集群。它的特點就不說了，很多人分析過。前段時間微博上說到zk有一些問題，其實只是某些場合下zk使用需要小心，這裡列舉一下 list 1 zk不適合做大資料量的儲存，簡單來說就是不適合做公用儲存。原因很簡單，每個資料要同步到所有server才返...
關於Zookeeper和dubbo的負載均衡問題
zookeeper是服務註冊中心 dubbo是服務提供和消費中心 當有消費者向dubbo需要乙個服務的時候，dubbo在zookeeper裡尋找是否有註冊過這樣的乙個服務，即是否有人提供過這個服務，如果有就提供，沒有就報錯。關於他們的負載均衡 在配置檔案中 第乙個註冊中心 第二個註冊中心 在兩個中心...
關於Zookeeper的原子廣播和崩潰恢復
1.zab zookeeper atomic broadcast 是一套專門為zookeeper設計的用於原子廣播和崩潰恢復的協議 2.zab基於2pc演算法進行設計，利用了過半性和paxos演算法進行了改進 atomic broadcast 原子廣播 1.作用 保證資料一致性。強一致性 最終一致性...