ZAB 協(xié)議的全稱是 Zookeeper Atomic Broadcase，原子廣播協(xié)議。

作用：通過這個 ZAB 協(xié)議可以進行集群間主備節(jié)點的數(shù)據(jù)同步，保證數(shù)據(jù)的一致性。

在講解 ZAB 協(xié)議之前，我們必須要了解 Zookeeper 的各節(jié)點的角色。

Zookeeper 各節(jié)點的角色

Leader：

• 負責(zé)處理客戶端發(fā)送的讀、寫事務(wù)請求。這里的事務(wù)請求可以理解這個請求具有事務(wù)的 ACID 特性。
• 同步寫事務(wù)請求給其他節(jié)點，且需要保證事務(wù)的順序性。
• 狀態(tài)為 LEADING。

Follower：

• 負責(zé)處理客戶端發(fā)送的讀請求
• 轉(zhuǎn)發(fā)寫事務(wù)請求給 Leader。
• 參與 Leader 的選舉。
• 狀態(tài)為 FOLLOWING。

Observer：

• 和 Follower 一樣，唯一不同的是，不參與 Leader 的選舉，且狀態(tài)為 OBSERING。
• 可以用來線性擴展讀的 QPS。

啟動階段，如何選 Leader？

Zookeeper 剛啟動的時候，多個節(jié)點需要找出一個 Leader。怎么找呢，就是用投票。

比如集群中有兩個節(jié)點，A 和 B，原理圖如下所示：

• 節(jié)點 A 先投票給自己，投票信息包含節(jié)點 id(SID) 和一個 ZXID，如 (1,0)。SID 是配置好的，且唯一，ZXID 是唯一的遞增編號。
• 節(jié)點 B 先投票給自己，投票信息為(2,0)。
• 然后節(jié)點 A 和 B 將自己的投票信息投票給集群中所有節(jié)點。
• 節(jié)點 A 收到節(jié)點 B 的投票信息后，檢查下節(jié)點 B 的狀態(tài)是否是本輪投票，以及是否是正在選舉(LOOKING)的狀態(tài)。
• 投票 PK：節(jié)點 A 會將自己的投票和別人的投票進行 PK，如果別的節(jié)點發(fā)過來的 ZXID 較大，則把自己的投票信息更新為別的節(jié)點發(fā)過來的投票信息，如果 ZXID 相等，則比較 SID。這里節(jié)點 A 和 節(jié)點 B 的 ZXID 相同，SID 的話，節(jié)點 B 要大些，所以節(jié)點 A 更新投票信息為(2，0)，然后將投票信息再次發(fā)送出去。而節(jié)點 B 不需要更新投票信息，但是下一輪還需要再次將投票發(fā)出去。

這個時候節(jié)點 A 的投票信息為(2，0)，如下圖所示：

• 統(tǒng)計投票：每一輪投票，都會統(tǒng)計每臺節(jié)點收到的投票信息，判斷是否有過半的節(jié)點收到了相同的投票信息。節(jié)點 A 和 節(jié)點 B 收到的投票信息都為(2，0)，且數(shù)量來說，大于一半節(jié)點的數(shù)量，所以將節(jié)點 B 選出來作為 Leader。
• 更新節(jié)點狀態(tài)：節(jié)點 A 作為 Follower，更新狀態(tài)為 FOLLOWING，節(jié)點 B 作為 Leader，更新狀態(tài)為 LEADING。

運行期間，Leader 宕機了怎么辦？

在 Zookeeper 運行期間，Leader 會一直保持為 LEADING 狀態(tài)，直到 Leader 宕機了，這個時候就要重新選 Leader，而選舉過程和啟動階段的選舉過程基本一致。

需要注意的點：

• 剩下的 Follower 進行選舉，Observer 不參與選舉。
• 投票信息中的 zxid 用的是本地磁盤日志文件中的。如果這個節(jié)點上的 zxid 較大，就會被當選為 Leader。如果 Follower 的 zxid 都相同，則 Follower 的節(jié)點 id 較大的會被選為 Leader。

節(jié)點之間如何同步數(shù)據(jù)的？

不同的客戶端可以分別連接到主節(jié)點或備用節(jié)點。

而客戶端發(fā)送讀寫請求時是不知道自己連的是Leader 還是 Follower，如果客戶端連的是主節(jié)點，發(fā)送了寫請求，那么 Leader 執(zhí)行 2PC(兩階段提交協(xié)議)同步給其他 Follower 和 Observer 就可以了。但是如果客戶端連的是 Follower，發(fā)送了寫請求，那么 Follower 會將寫請求轉(zhuǎn)發(fā)給 Leader，然后 Leader 再進行 2PC 同步數(shù)據(jù)給 Follower。

兩階段提交協(xié)議：

• 第一階段：Leader 先發(fā)送 proposal 給 Follower，F(xiàn)ollower 發(fā)送 ack 響應(yīng)給 Leader。如果收到的 ack 過半，則進入下一階段。
• 第二階段： Leader 從磁盤日志文件中加載數(shù)據(jù)到內(nèi)存中，Leader 發(fā)送 commit 消息給 Follower，F(xiàn)ollower 加載數(shù)據(jù)到內(nèi)存中。

我們來看下 Leader 同步數(shù)據(jù)的流程：

• ① 客戶端發(fā)送寫事務(wù)請求。
• ② Leader 收到寫請求后，轉(zhuǎn)化為一個 "proposal01：zxid1" 事務(wù)請求，存到磁盤日志文件。
• ③ 發(fā)送 proposal 給其他 Follower。
• ④ Follower 收到 proposal 后，F(xiàn)ollower 寫磁盤日志文件。

接著我們看下 Follower 收到 Leader 發(fā)送的 proposal 事務(wù)請求后，怎么處理的：

• ⑤ Follower 返回 ack 給 Leader。
• ⑥ Leader 收到超過一半的 ack，進行下一階段
• ⑦ Leader 將磁盤中的日志文件的 proposal 加載到 znode 內(nèi)存數(shù)據(jù)結(jié)構(gòu)中。
• ⑧ Leader 發(fā)送 commit 消息給所有 Follower 和 Observer。
• ⑨ Follower 收到 commit 消息后，將 磁盤中數(shù)據(jù)加載到 znode 內(nèi)存數(shù)據(jù)結(jié)構(gòu)中。

現(xiàn)在 Leader 和 Follower 的數(shù)據(jù)都是在內(nèi)存數(shù)據(jù)中的，且是一致的，客戶端從 Leader 和 Follower 讀到的數(shù)據(jù)都是一致的。

ZAB 的順序一致性怎么做到的？

Leader 發(fā)送 proposal 時，其實會為每個 Follower 創(chuàng)建一個隊列，都往各自的隊列中發(fā)送 proposal。

如下圖所示是 Zookeeper 的消息廣播流程：

客戶端發(fā)送了三條寫事務(wù)請求，對應(yīng)的 proposal 為：

proposal01:zxid1
proposal02:zxid2
proposal03:zxid3

Leader 收到請求后，依次放到隊列中，然后 Follower 依次從隊列中獲取請求，這樣就保證了數(shù)據(jù)的順序性。

Zookeeper 到底是不是強一致性？

官方定義：順序一致性。

不保證強一致性，為什么呢？

因為 Leader 再發(fā)送 commit 消息給所有 Follower 和 Observer 后，它們并不是同時完成 commit 的。

比如因為網(wǎng)絡(luò)原因，不同節(jié)點收到的 commit 較晚，那么提交的時間也較晚，就會出現(xiàn)多個節(jié)點的數(shù)據(jù)不一致，但是經(jīng)過短暫的時間后，所有節(jié)點都 commit 后，數(shù)據(jù)就保持同步了。

另外 Zookeeper 支持強一致性，就是手動調(diào)用 sync 方法來保證所有節(jié)點都 commit 才算成功。

這里有個問題：如果某個節(jié)點 commit 失敗，那么 Leader 會進行重試嗎？如何保證數(shù)據(jù)的一致性？歡迎討論。

Leader 宕機數(shù)據(jù)丟失問題

第一種情況：

假設(shè) Leader 已經(jīng)將消息寫入了本地磁盤，但是還沒有發(fā)送 proposal 給 Follower，這個時候 Leader 宕機了。

那就需要選新的 Leader，新 Leader 發(fā)送 proposal 的時候，包含的 zxid 自增規(guī)律會發(fā)生一次變化：

• zxid 的高 32 位自增 1 一次，高 32 位代表 Leader 的版本號。
• zxid 的低 32 位自增 1，后續(xù)還是繼續(xù)保持自增長。

當老 Leader 恢復(fù)后，會轉(zhuǎn)成 Follower，Leader 發(fā)送最新的 proposal 給它時，發(fā)現(xiàn)本地磁盤的 proposal 的 zxid 的高 32 位小于新 Leader 發(fā)送的 proposal，就丟棄自己的 proposal。

第二種情況：

如果 Leader 成功發(fā)送了 commit 消息給 Follower，但是所有或者部分 Follower 還沒來得及 commit 這個 proposal，也就是加載磁盤中的 proposal 到 內(nèi)存中，這個時候 Leader 宕機了。

那么就需要選出磁盤日志中 zxid 最大的 Follower，如果 zxid 相同，則比較節(jié)點 id，節(jié)點 id 大的作為 Leader。

本篇盡量用大白話+畫圖的方式進行講解，希望能給大家?guī)韱l(fā)。