Zookeeper_ZAB協議

ZAB協議

ZAB協議簡介

ZAB：（Zookeeper Atomic Broadcast），zk原子消息廣播協議，是專爲ZK設計的一中支持崩潰恢復的原子廣播協議，是一種Paxos協議的優化算法，在ZK中，主要依賴ZAB協議來實現分佈式數據的一致性

ZK使用一個單一主進程來接受並處理客戶端的全部事務請求，即寫請求，當服務器數據的狀態發射管變動時，集羣採用ZAB原子廣播協議，以事務提案Proposal的形式廣播道全部的副本進程上，ZAB協議可以保證一個全局的變動序列，便可覺得每個事務分配一個全局的遞增編號Xid.

當ZK客戶端鏈接到ZK集羣的任意節點後，若客戶端提交的讀請求，那麼當前節點就直接根據本身保存的數據對其進行響應，若是是寫請求且當前節點不是Leader，那麼節點就會將該寫請求請求轉發給Leader,Leader會以提案的方式廣播該寫操做，只要超過半數節點贊成該寫操做，則該寫操做請求就會被提交，而後Leader會再次廣播給全部的Learner,通知他們同步數據

集羣中的三種角色

爲了不ZK的單點問題，ZK也是以集羣的形式出現的，ZK集羣中的角色主要有如下三類

Leader：

集羣寫請求的惟一處理者，並負責進行投票的發起和決議，更新系統狀態，Leader是很明主的，在接受到一個一個寫請求的時候，會以廣播的方式提出一個提議，在大多數zkServer均贊成的狀況下才會做出修改

Follower：

接受客戶端的請求，處理讀請求時，直接響應結果，若是是寫請求的話，則是須要轉發給Leader處理；

在選舉Leader的過程當中參與投票；

Observer：

能夠看做是無選主投票權、寫操做投票權的Follower，他都不會計算在集羣的服務機器臺數中，主要的做用是爲了協助Follower處理更多的讀請求，當咱們ZK的讀請求的負載很高時，勢必要添加Follower身份的機器加入集羣，這樣集羣中的機器數量就會變得居多，拖慢寫操做的效率(機子越多通訊壓力就越大，Leader的選舉，寫操做的投票都更耗時)，這個時候咱們選擇添加Observer服務器，既能夠提升處理讀請求的吞吐量，集羣機器數量又沒有增長，豈不是美滋滋！

ZK服務的三種狀態

ZAB協議中對zkServer的狀態描述爲三種模式：恢復模式、同步模式、廣播模式

恢復模式：

在服務重啓過程當中，或者Leader崩潰後，就會進入到恢復模式，要恢復到ZK集羣正常的工做狀態

同步模式：

在全部的zkServer啓動完畢或者Leader崩潰後又選舉出來了新的的Leader,就會進入到同步模式，各個Follower須要立刻將Leader中的數據同步到本身的主機中，當完成數據同步後，同步模式旋蓋結束，同步模式被包含在恢復模式中

廣播模式：

當Leader的提議被大多數zkServer贊成後，Leader會修改自身數據，而後會將修改後的數據廣播給其餘的Follower

zxid

• zxid爲64位長度的Long類型，其中高32位表示紀元epoch，低32位表示事務標識xid；

• 每個Leader都會具備一個不一樣的epoch值，表示一個時代，每一次新的選舉開啓是都會生成一個新的epoch，新的Leader產生，則會更新全部zkServer的zxid中的epoch

• xid則爲ZK的事務id,每個寫操做都是一個事務，都會有一個xid,xid爲一個依次遞增的流水號，每個寫操做都須要由Leader發起一個提案，由全部的follower表決死都贊成本次寫操做，而每個提案都具備一個xid

消息廣播算法

當集羣中已經有過半的Follower與Leader服務器完成了狀態同步，那麼整個ZK集羣就能夠進入到消息廣播模式了

無非就是，若是來了一個寫請求，受理的節點不是LEader,就會請求轉發給Leader，Leader會爲其生成對應的全局惟一的64位自增zxid，經過zxid的大小比較，便可實現事務的有序性管理，

爲了保證Leader向Follower發送提案的有序性，，Leader會爲每個Follower建立一個FIFO隊列，並將提案寫入到該隊列中，而後經過隊列發送給Follower

當Follower接受到提案後，會先將提案的zxid與本地記錄的的事務日誌中最大的zxid進行比較，若提案中的zxid更大，則將該zxid記錄到本地進行覆蓋，而後響應Leader一個ACK回執

當Leader收到過半的ACK回執後,Leader就會向全部的Follower發送Commit消息，批准各個Follower在本地執行該消息，當Follower收到Commit消息後，就會執行事務提交，至於那些沒有響應回執的，Leader直接發對應的提案和一個Commit提交過去，直接完成數據的事務提交

恢復模式的兩個原則

當集羣正在啓動過程當中，或者Leader與超過半數的主機斷連後，集羣就會進入到恢復模式，對於要恢復的數據狀態須要遵循兩個原則

第一個：已經被處理的消息不能丟

當Leader收到超過半數的Follower的ACK回執後，就會向各個Follower廣播Commit消息，各個服務都在本地執行寫操做並完成事務提交，而後就會向客戶端響應寫操做成功，可是若是在非所有的Follower收到Commit以前Leader就掛掉了，這就會致使一部分server沒有收到事務提交請求，從而沒有完成數據的寫入，最後集羣中的機器中的數據不一致了，下面又要選取新的Leader了，ZK確定不容許那些沒有收到Commit請求的機器當選，由於他們的本地數據不完整，爲了保證"已經被處理的消息不能丟"，ZAB的恢復模式使用下面的這種策略

• 選舉擁有proposal最大值(即zxid最大)的節點做爲新的Leader,zxid最大的節點的數據確定是最完整的

• 新的Leader先將自身擁有的zxid，發送給全部的Follower,而後將這些zxid的commit命令發送給全部的Follower,保證全部的Follower都保存並執行了全部的zxid所對應的事務提交，這樣就會形成被處理過的消息不會丟失