ZAB協議

　　介紹

　　1、zab協議是為分布式協調服務zookpeer專門設計的一種支持崩潰恢復的原子廣播協議

　　2、在zookeeper中主要依賴ZAB協議來實現數據一致性，基於該協議zk實現了一種主備模式的系統架構來保證集群中各個副本之間數據的一致性。具體就是zk使用一個單一的主進程來接收並處理客戶端的事務請求（就是寫請求），並采用ZAB的原子廣播協議，將服務器數據的狀態變更以事務proposal的形式廣播到所有的副本進程上去。

　　事務請求的處理方式

　　所有的事務請求必須由一個全局唯一的服務器來協調處理，這樣的服務器被稱為Leader服務器，而余下的其他服務器則是Follow服務器。Leader負責將一個事務請求轉換成一個事務proposal，並將該proposal分發給集群中所有的Follow，之後Leader需要等待所有的Follow的反饋，一單超過半數Follow進行了正確的反饋後，那麽Leader就會再次向所有的Follow發送commit消息，要求其將前一個proposal進行提交

　　註意：如果集群中非Leader服務器接收到事務請求，這些非Leader服務器會將事務請求轉發給Leader服務器，只有Leader才能處理事務請求。

　　協議具體內容

　　ZAB協議包括兩種基本模式：分別是崩潰恢復和消息廣播

　　當整個集群啟動過程中或者當Leader服務器出現網絡中斷，崩潰退出或重啟等異常時，ZAB協議j就會進入恢復模式並選舉產生新的Leader，當選舉產生了新的Leader，同時集群中有過半的機器與該Leader服務器完成了狀態同步（即數據同步）之後，ZAB協議就會退出崩潰恢復模式，進入消息廣播模式。這時如果有一臺遵守ZAB協議的服務器加入集群，因為此時集群中已經存在一個Leader服務器在廣播消息，那麽新加入的服務器自覺的進入恢復模式：找到Leader服務器並與之完成數據同步然後一起參與到消息廣播流程中去。

　　當Leader出現崩潰退出或者機器重啟，亦或是集群中已經不存在過半的服務器與Leader保持正常的通信，ZAB就會重新發一輪Leader選舉並實現數據同步，最後又進入消息廣播模式，接收事務請求

　　消息必須是有順序的

　　在整個消息廣播過程中，Leader會將每個事務請求轉換成對應的proposal來進行廣播，並且在廣播事務proposal之前，Leader服務器會首先為這個事務proposal分配一個全局的單調遞增的唯一ID，稱之為事務ID（即ZXID），由於ZAB需要保證每一個消息嚴格的因果關系，因此必須將每一個proposal按照其ZXID的先後順序來進行排序與處理。

　　消息廣播

　　ZAB協議的消息廣播使用的是一個原子廣播協議，類似於二階段提交，Leader接收事務請求，並轉換成proposal廣播給其他的Follow，然後過半的Follow ack消息，最後再給廣播commit消息完成事務提交。

　　具體的，在消息廣播過程中，Leader為每個Follow服務器分配一個單獨的隊列，然後將需要廣播的proposal依次放到隊列中去，並且根據FIFO策略進行消息發送。每一個Follow接收到proposal後，都會首先將其以事務日誌的形式寫入本地磁盤中，並且寫入成功後反饋Leader一個ACK響應。當Leader接收到超過半數的ACK響應後，就會廣播一個commit消息給Follow已通知他們完成事務提交，同時Leader自身也會完成事務的提交。

　　崩潰恢復

　　Leader掛了之後，ZAB協議就自動進入崩潰恢復模式，選舉出新的Leader，並完成數據同步，然後退出崩潰恢復模式進入消息廣播模式

　　ZAB協議如何保證數據一致性

　　異常情況：

　　1、假設一個事務在Leader上提交了，並且過半Follow都響應ACK了，但是Leader將commit消息發出後就掛了

　　2、假設一個事務在Leader提交了之後，Leader就掛掉了。

　　要保證如果發生上述2種情況，數據還能保持一致性，那麽ZAB協議選舉算法必須確保已經提交的proposal（發送過commit消息），在Follow上也必須完成提交；並且丟棄已經被跳過的事務proposal。

通過ZAB協議選舉算法選舉出來的Leader必須是擁有集群中最高編號（ZXID）proposal的機器，擁有最高編號說明新Leader一定具有所有已提交的提案。更為重要的是，如果讓具有最高編號的事務proposal的機器成為Leader，就可以省去Leader服務器檢查proposal的提交和丟棄工作的這一步操作了。

　　ZAB是如何數據同步？

　　完成Leader選舉後（新Leader具有最高編號），在正式開始工作之前（接收事務請求，然後提出新的proposal）,Leader服務器會首先確認事務日誌中的所有的Proposal是否都已經被集群中過半的提交了。

　　Leader服務器需要確保所有的Follow服務器能夠接收到每一條事務proposal, 並且能將所有已經提交的事務proposal應用到內存數據庫中去。等到Follow將所有尚未同步的事務proposal都從Leader服務器上同步過來並應用到內存數據庫中去，Leader才會把該Follow加入到真正可用的Follow列表中。

　　ZAB是如何處理需要丟棄的Proposal？

　　在ZAB協議的事務編號ZXID設計中，ZXID是一個64位的數字，其中低32位可以看作成一個簡單的單調遞增計數器了，針對客戶端每一個事務請求，Leader在產生新的事務Proposal時，都會對該計數器加1，而高32位則代表了Leader周期的epoch編號（可以理解為選舉的屆期），每當選舉產生一個新的Leader，就會從這個Leader服務器上取出本地事務日誌中最大的編號proposal的ZXID，並從ZXID中解析得到對應epoch編號，然後再對其進行加1，之後就以此編號作為新的epoch值，並將地32位置為0開始生成新的ZXID，ZAB協議通過epoch編號來區分Leader變化周期，能夠有效的避免了不同的Leader錯誤的使用了相同的ZXID編號提出了不一樣的proposal的異常情況。

　　基於這樣的策略，當一個包含了上一個Leader周期中尚未提交過的事務proposal的服務器啟動時，當這臺機器加入集群中，以Follow角色連接上Leader服務器後，Leader服務器會根據自己服務器上最後提交的proposal來和Follow服務器的proposal進行比對，比對的結果肯定是Leader要求Follow進行一個回退操作，回退到一個確實已經被集群中過半機器提交的最新proposal。

　　ZAB協議特性：

　　1、ZAB協議需要確保那些已經在Leader服務器上提交（commit）的事務最終被所有的服務器提交

　　2、ZAB協議需要確保丟棄那些只在Leader上被提出的事務(只是被提出還沒有被提交)

理解ZAB協議