Zookeeper一致性協議——ZAB

ZAB協議簡介

Zookeeper通過ZAB保證分布式事務的最終一致性。

ZAB全稱Zookeeper Atomic Broadcast（ZAB，Zookeeper原子消息廣播協議）

1. ZAB是一種專門為Zookeeper設計的一種支持 崩潰恢復 的 原子廣播協議 ，是Zookeeper保證數據一致性的核心算法。ZAB借鑒了Paxos算法，但它不是通用的一致性算法，是特別為Zookeeper設計的。

2. 基於ZAB協議，Zookeeper實現了⼀種主備模式的系統架構來保持集群中各副本之間的數據的⼀致性，表現形式就是使⽤⼀個單⼀的主進程（Leader服務器）來接收並處理客戶端的所有事務請求（寫請求），並采⽤ZAB的原⼦⼴播協議，將服務器數據的狀態變更為事務 Proposal的形式⼴播到所有的Follower進程中。

問題提出

• 主從架構下，leader 崩潰，數據一致性怎么保證？
• 選舉 leader 的時候，整個集群無法處理寫請求的，如何快速進行 leader 選舉？

ZAB過程

ZAB協議的核⼼是 定義了對於那些會改變Zookeeper服務器數據狀態的事務請求的處理⽅式

所有事務必須由一個 全局唯一的服務器來協調處理 ，這樣的服務器被稱為Leader服務器，余下的服務器則稱為Follower服務器

1. Leader服務器負責將一個客戶端事務請求轉化為一個事務Proposal（提案），並將該Proposal分發給集群中所有的Follower服務器
2. Leader服務器等待所有Follower服務器的反饋，一旦超過半數的Follower服務器進行了正確的反饋后，Leader就會向所有的Follower服務器發送Commit消息，要求將前一個Proposal進行提交。

ZAB協議內容簡介

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

消息廣播

當集群中有過半的Follower服務器完成了和Leader服務器的狀態同步，那么整個服務框架就可以進入 消息廣播模式 。

當一台遵守ZAB協議的服務器啟動后加入到集群中，如果此時集群中已經存在一個Leader服務器在負責進行消息廣播，那么加入的服務器會自覺的進入 數據恢復模式： 找到Leader 所在的服務器，並與其進⾏數據同步，數據同步完成后參與到消息⼴播流程中。

ZAB協議的消息廣播使用原子廣播協議， 類似一個二階段提交的過程 ，但又有所不同。

1. 二階段提交中，需要所有參與者反饋ACK后再發送Commit請求。要求所有參與者要么成功，要么失敗。這樣會產生嚴重的阻塞問題
2. ZAB協議中，Leader等待半數以上的Follower成功反饋ACK即可，不需要收到全部的Follower反饋ACK。

消息廣播過程：

1. 客戶端發起寫請求
2. Leader將客戶端請求信息轉化為事務Proposal，同時為每個Proposal分配一個事務ID（Zxid）
3. Leader為每個Follower單獨分配一個FIFO的隊列，將需要廣播的Proposal依次放入到隊列中
4. Follower接收到Proposal后，首先將其以事務日志的方式寫入到本地磁盤中，寫入成功后給Leader反饋一個ACK響應
5. Leader接收到半數以上Follower的ACK響應后，即認為消息發送成功，可以發送Commit消息
6. Leader向所有Follower廣播Commit消息，同時自身也會完成事務提交。Follower接收到Commit消息后也會完成事務的提交

崩潰恢復

在整個服務框架啟動過程中，如果Leader服務器出現網絡中斷、崩潰退出或重啟等異常情況，ZAB協議就會進入崩潰恢復模式。同時選舉出新的Leader服務器。

當選舉產生了新的Leader服務器，同時集群中已經有過半的機器與該Leader服務器完成了狀態同步（數據同步）之后，ZAB協議會退出恢復模式。

1. 在ZAB協議中，為了保證程序的正確運⾏，整個恢復過程結束后需要選舉出⼀個新的Leader 服務器。
2. Leader選舉算法不僅僅需要讓Leader⾃身知道已經被選舉為Leader，同時還需要讓集群中的所有其他機器也能夠快速地感知到選舉產⽣出來的新Leader服務器。

ZAB保證數據一致性

ZAB協議規定了 如果⼀個事務Proposal在⼀台機器上被處理成功，那么應該在所有的機器上都被處理成功，哪怕機器出現故障崩潰。 針對這些情況ZAB協議需要保證以下條件：

• 已經在Leader服務器上提交的事務最終被所有服務器都提交。

  假設⼀個事務在 Leader 服務器上被提交了，並且已經得到過半 Folower 服務器的Ack反饋，但是在它 將Commit消息發送給所有Follower機器之前，Leader服務器掛了

• 丟棄只在Leader服務器上被提出（未提交）的事務。

  假設初始的 Leader 服務器 Server1 在提出了⼀個事務Proposal3 之后就崩潰退出 了，從⽽導致集群中的其他服務器都沒有收到這個事務Proposal3。於是，當 Server1 恢復過來再次加 ⼊到集群中的時候，ZAB 協議需要確保丟棄Proposal3這個事務。

綜上所述，ZAB的選舉出來的Leader必須滿足以下條件：

能夠確保提交已經被 Leader 提交的事務 Proposal，同時丟棄已經被跳過的事務 Proposal。即：

1. 新選舉出來的 Leader 不能包含未提交的 Proposal。
2. 新選舉的 Leader 節點中含有最大的 zxid 。

ZAB如何數據同步

所有正常運行的服務器要么成為Leader，要么成為Follower並和Leader保持同步。

1. 完成Leader選舉（新的 Leader 具有最高的zxid）之后，在正式開始⼯作（接收客戶端請求）之前，Leader服務器會⾸先確認事務⽇志中的所有Proposal是否都已經被集群中過半的機器提交了，即 是否完成數據同步 。

2. Leader服務器需要確保所有的Follower服務器能夠接收到每⼀條事務Proposal，並且能夠正確地將所有已經提交了的事務Proposal應⽤到內存數據中。等到 Follower服務器將所有其尚未同步的事務 Proposal 都從 Leader 服務器上同步過來並成功應⽤到本地數據庫中后，Leader服務器就會將該Follower服務器加⼊到真正的可⽤Follower列表中，並開始之后的其他流程。

ZAB運行時狀態

ZAB協議設計中，每個進程都有可能處於如下三種狀態之一：

• LOOKING：Leader選舉狀態，正在尋找Leader
• FOLLOWING：當前節點是Follower。與Leader服務器保持同步狀態
• LEADING：當前節點是Leader，作為主進程領導狀態。

ZAB狀態的切換

啟動時的狀態轉換

1. 所有進程的初始狀態都是LOOKING狀態，此時不存在Leader。

2. 接下來，進程會試圖選舉出來一個新的Leader，Leader切換為LEADING狀態，其它進程發現已經選舉出新的Leader，那么它就會切換到FOLLOWING狀態，並開始與Leader保持同步。

3. 處於FOLLOWING狀態的進程稱為Follower，LEADING狀態的進程稱為Leader。

4. 當Leader崩潰或者放棄領導地位時，其余的Follower進程就會切換到LOOKING狀態開始新一輪的Leader選舉。

運行過程中的狀態轉換

一個Follower只能和一個Leader保持同步，Leader進程和所有的Follower進程之間通過心跳監測機制來感知彼此的情況。

1. 若Leader能夠在超時時間內正常的收到心跳檢測，那么Follower就會一直與該Leader保持連接。
2. 如果在指定時間內Leader無法從過半的Follower進程那里接收到心跳檢測，或者TCP連接斷開，那么Leader會放棄當前周期的領導，並轉換為LOOKING狀態；其他的Follower也會選擇放棄這個Leader，同時轉換為LOOKING狀態，之后會進行新一輪的Leader選舉

ZAB的四個階段

選舉階段（Leader Election）

節點在一開始都處於選舉階段，只要有一個節點超過半數階段的票數，它就可以當選准Leader，只有到達第三個階段（同步階段），這個准Leader才會成為真正的Leader。

這一階段的目的就是為了選出一個准Leader，然后進入下一階段。

發現階段

在這個階段中，Followers和上一輪選舉出的准Leader進行通信，同步Followers最近接受的事務Proposal。這個階段主要目的是發現當前大多數節點接受的最新提議，並且准Leader生成新的epoch，讓Followers接受，更新它們的acceptedEpoch。

一個Follower只會連接一個Leader，如果有一個節點F認為另一個Follower P是Leader，F在嘗試連接P時會被拒絕，F被拒絕后，就會進入選舉階段。

同步階段

同步階段主要是利用 Leader 前一階段獲得的最新 Proposal 歷史，同步集群中所有的副本。

只有當 quorum（超過半數的節點） 都同步完成，准 Leader 才會成為真正的 Leader。Follower 只會接收 zxid 比自己 lastZxid 大的 Proposal。

廣播階段

到了這個階段，Zookeeper 集群才能正式對外提供事務服務，並且 Leader 可以進行消息廣播。同時，如果有新的節點加入，還需要對新節點進行同步。
需要注意的是，Zab 提交事務並不像 2PC 一樣需要全部 Follower 都 Ack，只需要得到 quorum（超過半數的節點）的Ack 就可以。

ZAB協議實現

Java 版本的ZAB協議的實現跟上面的定義略有不同，選舉階段使用的是 Fast Leader Election（FLE），它包含了步驟2的發現職責。因為FLE會選舉擁有最新提議的歷史節點作為 Leader，這樣就省去了發現最新提議的步驟。

實際的實現將 發現和同步階段合並為 Recovery Phase（恢復階段） ，所以，Zab 的實現實際上有三個階段。

快速選舉（Fast Leader Election）

前面提到的 FLE 會選舉擁有最新Proposal history （lastZxid最大）的節點作為 Leader，這樣就省去了發現最新提議的步驟。 這是基於擁有最新提議的節點也擁有最新的提交記錄

成為Leader的條件：

1. 選epoch最大的
2. epoch相等，選zxid最大的
3. epoch和zxid都相等，選server_id最大的（zoo.cfg 中配置的 myid）

節點在選舉開始時，都默認投票給自己，當接收其他節點的選票時，會根據上面的 Leader條件 判斷並且更改自己的選票，然后重新發送選票給其他節點。當有一個節點的得票超過半數，該節點會設置自己的狀態為 Leading ，其他節點會設置自己的狀態為 Following。

恢復階段（Recovery Phase）

這一階段 Follower 發送他們的 lastZxid 給 Leader，Leader 根據 lastZxid 決定如何同步數據。這里的實現跟前面的 階段 3 有所不同：Follower 收到 TRUNC 指令會終止 L.lastCommitedZxid 之后的 Proposal ，收到 DIFF 指令會接收新的 Proposal。

history.lastCommittedZxid：最近被提交的提議的 zxid
history.oldThreshold：被認為已經太舊的已提交提議的 zxid

廣播階段（Broadcast Phase）

參考 4.1 [ZAB協議內容#消息廣播]

ZAB與Paxos的聯系和區別

聯系

1. 都存在一個類似Leader進程的角色，由其負責協調多個Follower進程的運行
2. Leader進程都會等待超過半數的Follower作出正確的反饋后，才會將一個提議進行提交（過半原則）
3. 在ZAB中，每個Proposal中都包含了一個epoch值，用來代表當前Leader周期，在Paxos中同樣存在這樣的一個表示，名字為 Ballot。

區別

1. Paxos算法中，新選舉產生的主進程會進行兩個階段的工作；第一階段稱為讀階段：新的主進程和其他進程通信來收集主進程提出的提議，並將它們提交。第二階段稱為寫階段：當前主進程開始提出自己的提議。
2. ZAB協議在Paxos基礎上添加了同步階段，此時，新的Leader會確保存在過半的Follower已經提交了之前Leader周期中的所有事物Proposal。這一同步階段的引入，能夠有效保證，Leader在新的周期中提出事務Proposal之前，所有的進程都已經完成了對之前所有事務Proposal的提交。

總的來說，ZAB協議和Paxos算法的本質區別在於兩者的設計目的不一樣：ZAB協議主要用於構建一個高可用的分布式數據主備系統，而Paxos算法則用於構建一個分布式的一致性狀態機系統。

總結

問題解答：

• 主從架構下，leader 崩潰，數據一致性怎么保證？

  leader 崩潰之后，集群會選出新的 leader，然后就會進入恢復階段，新的 leader 具有所有已經提交的提議，因此它會保證讓 followers 同步已提交的提議，丟棄未提交的提議（以 leader 的記錄為准），這就保證了整個集群的數據一致性。

• 選舉 leader 的時候，整個集群無法處理寫請求的，如何快速進行 leader 選舉？

  這是通過 Fast Leader Election 實現的，leader 的選舉只需要超過半數的節點投票即可，這樣不需要等待所有節點的選票，能夠盡早選出 leader。