只針對zookeeper的崩潰可恢復的原子訊息廣播協議。
zookeeper使用乙個單一的主程序來接收並處理客戶端的事務處理，並採用zab協議，將伺服器資料的狀態變更以事務proposal的形式廣播道所有的副本程序上去。zab協議的這個主備模型架構保證了同一時刻集群中只能夠有乙個主程序來廣播伺服器的狀態變更。zab能夠保證乙個全域性的變更序列被應用。zab協議還要保證，當主程序出現崩潰或重啟時，能夠繼續工作。
核心所有事務請求必須由乙個全域性唯一的伺服器來協調處理，這樣的伺服器被稱為leader伺服器，而餘下的其他伺服器則成為follower伺服器。leader伺服器負責將乙個客戶端事務請求轉換成乙個事務proposal，並將該proposal傳送給集群中所有的follower,當有超過半數的follower進行了正確反饋之後，那麼leader會再傳送乙個commit，要求其將前乙個proposal進行提交。
協議介紹
zab協議有崩潰恢復和訊息廣播。
深入zab協議
階段一:發現，follower將自己的epoch值傳送給準leader，準leader會選擇出最大的epoch值，並加1，標記為e『。準leader將e』傳送給follower，follower將自己的opoch值設定為e』，同時向這個leader返回ack訊息，這個ack訊息包含了當前的epoch值以及歷史事務proposal集合h。準leader會從中選擇zxid最大的事務集合，作為初始化事務集合ie』。
階段二:同步，leader以newleader(e』, ie』)訊息的形式傳送給所有quorum中的follower。當follower接收到來自leader l的newleader(e』,ie』)後，會執行事務應用應用，並反饋給leader。當leader收到超過半數的follower的反饋，就會向所有的follower傳送commit訊息。當follower收到來自leader的commit訊息後，會以此處理並提交所有在ie』中未處理的事務。至此階段二完成。
階段三:廣播，leader 接收到客戶端新的事務請求後，會生成對應的事務proposal，並向所有的follower傳送。follower處理事務，並反饋給leader。當leader有超過半數的正確響應之後，就會向所有的follower傳送commit。follower接收到之後，就會開始commit。
執行狀態分析
在zab的設計中，每個程序可能都處於以下狀態之一: loking,following,leading。所有程序啟動的時候，都處於looking狀態。如果選舉出新的leader了，那麼非leader就會馬上切換為following狀態，並開始與leader保持同步，leader則會進入leading狀態。當leader掛掉或放棄領導地位時，其餘follower就會轉為looking狀態，並開始進行新一輪leader選舉。因此，在zab協議執行過程中，每個程序在leading,following和looking狀態之間不斷地轉換。在原子廣播階段，leader會為每個follower單獨搞乙個佇列進行事務proposal傳送，如果超過半數的follower和leader失聯，那麼leader會進去looking狀態，也就是前面所說的放棄領導地位。
ZAB 協議演算法
zookeeper 最核心的作用就是保證分布式系統的資料一致性，而無論是處理來自客戶端的會話請求時，還是集群 leader 節點發生重新選舉時，都會產生資料不一致的情況。為了解決這個問題，zookeeper 採用了 zab 協議演算法。zab 協議演算法 zookeeper atomic broad...
Zookeeper理解 ZAB協議
zab協議 協議介紹 關鍵字 過半數節點 訊息廣播 順序性保證 奔潰恢復 基本特性 leader選舉 資料同步 丟棄資料 結論 深入zab協議 系統模型 存在任意q q是 的子集 q，q 存在任意時候的q1 q2，他們的交集不等於空集合 此處的意義在於q1或q2 任意乙個都超過半數，應此不管如何去交...
怎麼理解 ZAB 協議？
zab協議是為分布式協調服務 zookeeper 專門設計的一種支援崩潰恢復的原子廣播協議。zab 協議包括兩種基本的模式 崩潰恢復 和 訊息廣播。當整個 zookeeper 集群 剛剛啟動或者 leader 伺服器宕機 重啟或者網路故障導致不存在過半的伺服器與 leader 伺服器保持正常通訊時，...