zookeeper 最核心的作用就是保證分布式系統的資料一致性，而無論是處理來自客戶端的會話請求時，還是集群 leader 節點發生重新選舉時，都會產生資料不一致的情況。為了解決這個問題，zookeeper 採用了 zab 協議演算法。
zab 協議演算法(zookeeper atomic broadcast ，zookeeper 原子廣播協議)是 zookeeper 專門設計用來解決集群最終一致性問題的演算法，它的兩個核心功能點是崩潰恢復和原子廣播協議。
崩潰恢復
崩潰恢復機制是保證 zookeeper 集群服務高可用的關鍵。觸發 zookeeper 集群執行崩潰恢復的事件是集群中的 leader 節點伺服器發生了異常而無法工作，於是 follow 伺服器會通過投票來決定是否選出新的 leader 節點伺服器。
投票過程如下：當崩潰恢復機制開始的時候，整個 zookeeper 集群的每台 follow 伺服器會發起投票，並同步給集群中的其他 follow 伺服器。在接收到來自集群中的其他 follow 伺服器的投票資訊後，集群中的每個 follow 伺服器都會與自身的投票資訊進行對比，如果判斷新的投票資訊更合適，則採用新的投票資訊作為自己的投票資訊。在集群中的投票資訊還沒有達到超過半數原則的情況下，再進行新一輪的投票，最終當整個 zookeeper 集群中的 follow 伺服器超過半數投出的結果相同的時候，就會產生新的 leader 伺服器。
訊息廣播
在 leader 節點伺服器處理請求後，需要通知集群中的其他角色伺服器進行資料同步。zookeeper 集群採用訊息廣播的方式傳送通知。
zookeeper 集群使用原子廣播協議進行訊息傳送，如下圖所示
當要在集群中的其他角色伺服器進行資料同步的時候，leader 伺服器將該操作過程封裝成乙個 proposal 提交事務，並將其傳送給集群中其他需要進行資料同步的伺服器。當這些伺服器接收到 leader 伺服器的資料同步事務後，會將該條事務能否在本地正常執行的結果反饋給 leader 伺服器，leader 伺服器在接收到其他 follow 伺服器的反饋資訊後進行統計，判斷是否在集群中執行本次事務操作。
ZAB協議剖析
只針對zookeeper的崩潰可恢復的原子訊息廣播協議。zookeeper使用乙個單一的主程序來接收並處理客戶端的事務處理，並採用zab協議，將伺服器資料的狀態變更以事務proposal的形式廣播道所有的副本程序上去。zab協議的這個主備模型架構保證了同一時刻集群中只能夠有乙個主程序來廣播伺服器的狀...
Zookeeper理解 ZAB協議
zab協議 協議介紹 關鍵字 過半數節點 訊息廣播 順序性保證 奔潰恢復 基本特性 leader選舉 資料同步 丟棄資料 結論 深入zab協議 系統模型 存在任意q q是 的子集 q，q 存在任意時候的q1 q2，他們的交集不等於空集合 此處的意義在於q1或q2 任意乙個都超過半數，應此不管如何去交...
怎麼理解 ZAB 協議？
zab協議是為分布式協調服務 zookeeper 專門設計的一種支援崩潰恢復的原子廣播協議。zab 協議包括兩種基本的模式 崩潰恢復 和 訊息廣播。當整個 zookeeper 集群 剛剛啟動或者 leader 伺服器宕機 重啟或者網路故障導致不存在過半的伺服器與 leader 伺服器保持正常通訊時，...