點擊上方“朱小廝的博客”，選擇“設為星標”

后臺回復"書"，獲取

后臺回復“k8s”，可領取k8s資料

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

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

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

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

問題提出

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

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

ZAB過程

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

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

Leader服務器負責將一個客戶端事務請求轉化為一個事務Proposal（提案），并將該Proposal分發給集群中所有的Follower服務器

Leader服務器等待所有Follower服務器的反饋，一旦超過半數的Follower服務器進行了正確的反饋后，Leader就會向所有的Follower服務器發送Commit消息，要求將前一個Proposal進行提交。

ZAB協議內容簡介

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

消息廣播

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

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

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

二階段提交中，需要所有參與者反饋ACK后再發送Commit請求。要求所有參與者要么成功，要么失敗。這樣會產生嚴重的阻塞問題

ZAB協議中，Leader等待半數以上的Follower成功反饋ACK即可，不需要收到全部的Follower反饋ACK。

消息廣播過程：

客戶端發起寫請求

Leader將客戶端請求信息轉化為事務Proposal，同時為每個Proposal分配一個事務ID（Zxid）

Leader為每個Follower單獨分配一個FIFO的隊列，將需要廣播的Proposal依次放入到隊列中

Follower接收到Proposal后，首先將其以事務日志的方式寫入到本地磁盤中，寫入成功后給Leader反饋一個ACK響應

Leader接收到半數以上Follower的ACK響應后，即認為消息發送成功，可以發送Commit消息

Leader向所有Follower廣播Commit消息，同時自身也會完成事務提交。Follower接收到Commit消息后也會完成事務的提交

崩潰恢復

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

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

在ZAB協議中，為了保證程序的正確運?，整個恢復過程結束后需要選舉出?個新的Leader 服務器。

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。即：

新選舉出來的 Leader 不能包含未提交的 Proposal。

新選舉的 Leader 節點中含有最大的 zxid?。

ZAB如何數據同步

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

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

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

ZAB運行時狀態#

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

• LOOKING：Leader選舉狀態，正在尋找Leader

• FOLLOWING：當前節點是Follower。與Leader服務器保持同步狀態

• LEADING：當前節點是Leader，作為主進程領導狀態。

ZAB狀態的切換

啟動時的狀態轉換

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

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

處于FOLLOWING狀態的進程稱為Follower，LEADING狀態的進程稱為Leader。

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

運行過程中的狀態轉換

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

若Leader能夠在超時時間內正常的收到心跳檢測，那么Follower就會一直與該Leader保持連接。

如果在指定時間內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被拒絕后，就會進入選舉階段。

ZAB-發現階段

同步階段

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

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

ZAB同步階段

廣播階段

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

ZAB廣播階段

ZAB協議實現

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

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

快速選舉（Fast Leader Election

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

成為Leader的條件：

選epoch最大的

epoch相等，選zxid最大的

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的聯系和區別

聯系

都存在一個類似Leader進程的角色，由其負責協調多個Follower進程的運行

Leader進程都會等待超過半數的Follower作出正確的反饋后，才會將一個提議進行提交（過半原則）

在ZAB中，每個Proposal中都包含了一個epoch值，用來代表當前Leader周期，在Paxos中同樣存在這樣的一個表示，名字為 Ballot。

區別

Paxos算法中，新選舉產生的主進程會進行兩個階段的工作；第一階段稱為讀階段：新的主進程和其他進程通信來收集主進程提出的提議，并將它們提交。第二階段稱為寫階段：當前主進程開始提出自己的提議。

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。

來源 |?https://urlify.cn/RRziQf

想知道更多？掃描下面的二維碼關注我

后臺回復"技術"，加入技術群

后臺回復“k8s”，可領取k8s資料

【精彩推薦】

• 原創|OpenAPI標準規范

• 中臺不是萬能藥，關于中臺的思考和嘗試
  

• ClickHouse到底是什么？為什么如此牛逼！

• 原來ElasticSearch還可以這么理解

• 面試官：InnoDB中一棵B+樹可以存放多少行數據？

• 微服務下如何解耦？對于已經緊耦合下如何重構？

• 如何構建一套高性能、高可用、低成本的視頻處理系統？

• 架構之道：分離業務邏輯和技術細節

• 星巴克不使用兩階段提交
  

點個贊+在看，少個 bug?????

總結

以上是生活随笔為你收集整理的面试官问：ZooKeeper是强一致的吗？怎么实现的？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。