- ZAB協議是專門爲zookeeper實現分佈式協調功能而設計。zookeeper主要是根據ZAB協議是實現分佈式系統數據一致性。
- zookeeper根據ZAB協議建立了主備模型完成zookeeper集羣中數據的同步。這裏所說的主備系統架構模型是指，在zookeeper集羣中，只有一臺leader負責處理外部客戶端的事物請求(或寫操作)，然後leader服務器將客戶端的寫操作數據同步到所有的follower節點中。
- ZAB的協議核心是在整個zookeeper集羣中只有一個節點即Leader將客戶端的寫操作轉化爲事物(或提議proposal)。Leader節點再數據寫完之後，將向所有的follower節點發送數據廣播請求(或數據複製)，等待所有的follower節點反饋。在ZAB協議中，只要超過半數follower節點反饋OK，Leader節點就會向所有的follower服務器發送commit消息。即將leader節點上的數據同步到follower節點之上。
- ZAB協議中主要有兩種模式，第一是消息廣播模式；第二是崩潰恢復模式
消息廣播模式
- 在zookeeper集羣中數據副本的傳遞策略就是採用消息廣播模式。zookeeper中數據副本的同步方式與二階段提交相似但是卻又不同。二階段提交的要求協調者必須等到所有的參與者全部反饋ACK確認消息後，再發送commit消息。要求所有的參與者要麼全部成功要麼全部失敗。二階段提交會產生嚴重阻塞問題。
- ZAB協議中Leader等待follower的ACK反饋是指”只要半數以上的follower成功反饋即可，不需要收到全部follower反饋”
- 圖中展示了消息廣播的具體流程圖
- zookeeper中消息廣播的具體步驟如下：
4.1. 客戶端發起一個寫操作請求
4.2. Leader服務器將客戶端的request請求轉化爲事物proposql提案，同時爲每個proposal分配一個全局唯一的ID，即ZXID。
4.3. leader服務器與每個follower之間都有一個隊列，leader將消息發送到該隊列
4.4. follower機器從隊列中取出消息處理完(寫入本地事物日誌中)畢後，向leader服務器發送ACK確認。
4.5. leader服務器收到半數以上的follower的ACK後，即認爲可以發送commit
4.6. leader向所有的follower服務器發送commit消息。 - zookeeper採用ZAB協議的核心就是只要有一臺服務器提交了proposal，就要確保所有的服務器最終都能正確提交proposal。這也是CAP/BASE最終實現一致性的一個體現。
- leader服務器與每個follower之間都有一個單獨的隊列進行收發消息，使用隊列消息可以做到異步解耦。leader和follower之間只要往隊列中發送了消息即可。如果使用同步方式容易引起阻塞。性能上要下降很多。
崩潰恢復
- zookeeper集羣中爲保證任何所有進程能夠有序的順序執行，只能是leader服務器接受寫請求，即使是follower服務器接受到客戶端的請求，也會轉發到leader服務器進行處理。
- 如果leader服務器發生崩潰，則zab協議要求zookeeper集羣進行崩潰恢復和leader服務器選舉。
- ZAB協議崩潰恢復要求滿足如下2個要求：
3.1. 確保已經被leader提交的proposal必須最終被所有的follower服務器提交。
3.2. 確保丟棄已經被leader出的但是沒有被提交的proposal。 - 根據上述要求，新選舉出來的leader不能包含未提交的proposal，即新選舉的leader必須都是已經提交了的proposal的follower服務器節點。同時，新選舉的leader節點中含有最高的ZXID。這樣做的好處就是可以避免了leader服務器檢查proposal的提交和丟棄工作。
- leader服務器發生崩潰時分爲如下場景：
5.1. leader在提出proposal時未提交之前崩潰，則經過崩潰恢復之後，新選舉的leader一定不能是剛纔的leader。因爲這個leader存在未提交的proposal。
5.2 leader在發送commit消息之後，崩潰。即消息已經發送到隊列中。經過崩潰恢復之後，參與選舉的follower服務器(剛纔崩潰的leader有可能已經恢復運行，也屬於follower節點範疇)中有的節點已經是消費了隊列中所有的commit消息。即該follower節點將會被選舉爲最新的leader。剩下動作就是數據同步過程。
數據同步
- 在zookeeper集羣中新的leader選舉成功之後，leader會將自身的提交的最大proposal的事物ZXID發送給其他的follower節點。follower節點會根據leader的消息進行回退或者是數據同步操作。最終目的要保證集羣中所有節點的數據副本保持一致。
- 數據同步完之後，zookeeper集羣如何保證新選舉的leader分配的ZXID是全局唯一呢？這個就要從ZXID的設計談起。
2.1 ZXID是一個長度64位的數字，其中低32位是按照數字遞增，即每次客戶端發起一個proposal,低32位的數字簡單加1。高32位是leader週期的epoch編號，至於這個編號如何產生(我也沒有搞明白)，每當選舉出一個新的leader時，新的leader就從本地事物日誌中取出ZXID,然後解析出高32位的epoch編號，進行加1，再將低32位的全部設置爲0。這樣就保證了每次新選舉的leader後，保證了ZXID的唯一性而且是保證遞增的。
ZAB協議原理
- ZAB協議要求每個leader都要經歷三個階段，即發現，同步，廣播。
- 發現：即要求zookeeper集羣必須選擇出一個leader進程，同時leader會維護一個follower可用列表。將來客戶端可以這follower中的節點進行通信。
- 同步：leader要負責將本身的數據與follower完成同步，做到多副本存儲。這樣也是體現了CAP中高可用和分區容錯。follower將隊列中未處理完的請求消費完成後，寫入本地事物日誌中。
- 廣播：leader可以接受客戶端新的proposal請求，將新的proposal請求廣播給所有的follower。
Zookeeper設計目標
- zookeeper作爲當今最流行的分佈式系統應用協調框架，採用zab協議的最大目標就是建立一個高可用可擴展的分佈式數據主備系統。即在任何時刻只要leader發生宕機，都能保證分佈式系統數據的可靠性和最終一致性。
- 深刻理解ZAB協議，才能更好的理解zookeeper對於分佈式系統建設的重要性。以及爲什麼採用zookeeper就能保證分佈式系統中數據最終一致性，服務的高可用性。