文章目錄

• ZAB協(xié)議
• • 消息廣播
  • 崩潰恢復(fù)

---

ZAB協(xié)議

ZAB（ZooKeeper Atomic Broadcast 原子廣播） 協(xié)議是為分布式協(xié)調(diào)服務(wù)ZooKeeper專門(mén)設(shè)計(jì)的一種支持崩潰恢復(fù)的原子廣播協(xié)議。 在ZooKeeper中，主要依賴ZAB協(xié)議來(lái)實(shí)現(xiàn)分布式數(shù)據(jù)一致性，基于該協(xié)議，ZooKeeper實(shí)現(xiàn)了一種主備模式的系統(tǒng)架構(gòu)來(lái)保持集群中各個(gè)副本之間的數(shù)據(jù)一致性。

ZAB協(xié)議包括了兩種基本的模式，分別是崩潰恢復(fù)和消息廣播。

消息廣播

為了保證集群中存在過(guò)半的機(jī)器能夠和Leader服務(wù)器的數(shù)據(jù)狀態(tài)保持一致，ZAB協(xié)議中引入了消息廣播模式。

在上面我們提到了，ZooKeeper集群中只有Leader服務(wù)器能夠執(zhí)行寫(xiě)操作，為了保證集群的數(shù)據(jù)一致性，我們需要將Leader節(jié)點(diǎn)更新的數(shù)據(jù)同步到Follower與Observer服務(wù)器中，所以當(dāng)Leader服務(wù)器接收到客戶端發(fā)送的寫(xiě)請(qǐng)求后，會(huì)自動(dòng)生成對(duì)應(yīng)的提案并發(fā)起一輪消息廣播。

消息廣播的執(zhí)行流程如下：

接受到客戶端發(fā)送的事務(wù)請(qǐng)求，Leader服務(wù)器為其生成對(duì)應(yīng)的事務(wù)提議。

Leader為每一個(gè)Follower和Observer都準(zhǔn)備了一個(gè)FIFO的隊(duì)列，并把提議發(fā)送到隊(duì)列上。

當(dāng)Follower接收到事務(wù)提議后，都會(huì)先將其以事務(wù)日志的形式寫(xiě)入本地磁盤(pán)中，然后再寫(xiě)入成功后反饋給Leader服務(wù)器一個(gè)ACK。

當(dāng)Leader接收到半數(shù)以上Follower節(jié)點(diǎn)的ACK，它就會(huì)認(rèn)為大部分節(jié)點(diǎn)都同意議題，準(zhǔn)備開(kāi)始提交。

Leader向所有節(jié)點(diǎn)發(fā)送提交事務(wù)的Commit請(qǐng)求，完成事務(wù)。

消息廣播流程
為了防止因?yàn)榫W(wǎng)絡(luò)等原因?qū)е碌腇ollower、Observer節(jié)點(diǎn)處理請(qǐng)求的順序不同而導(dǎo)致的數(shù)據(jù)不一致問(wèn)題，保證消息廣播過(guò)程中消息接收與發(fā)送的順序性，消息廣播中引入了**FIFO隊(duì)列**和**事務(wù)ID**來(lái)解決這個(gè)問(wèn)題。

• 在消息廣播的過(guò)程中，Leader服務(wù)器會(huì)為每一個(gè)Follower、Observer服務(wù)器都各自分配一個(gè)單獨(dú)的隊(duì)列，然后將需要廣播的事務(wù)提議放到這些隊(duì)列中，并根據(jù)FIFO策略進(jìn)行消息發(fā)送。由于ZAB由于協(xié)議是通過(guò)TCP協(xié)議來(lái)進(jìn)行網(wǎng)絡(luò)通信的，這樣不僅保證了消息的發(fā)送順序性，也保證了接受順序性。
• 在廣播事務(wù)提議之前，Leader服務(wù)器會(huì)先給這個(gè)提議分配一個(gè)全局單調(diào)遞增的唯一事務(wù)ID（ZXID）。為了保證每一個(gè)消息嚴(yán)格的因果關(guān)系，必須將每一個(gè)事務(wù)提議按照其ZXID的先后順序來(lái)進(jìn)行排序與處理。

如果你了解過(guò)二階段提交（2PC）協(xié)議，你會(huì)發(fā)現(xiàn)其實(shí)消息廣播的過(guò)程實(shí)際上就是一個(gè)簡(jiǎn)化版本的二階段提交過(guò)程，他將二階段提交中的中斷邏輯刪除，Leader服務(wù)器不需要等待集群中的全部Follower服務(wù)器都響應(yīng)反饋，只需要得到過(guò)半Follower的ACK就開(kāi)始執(zhí)行事務(wù)的提交。這種簡(jiǎn)化版的2PC雖然提高了效率，但是無(wú)法處理Leader服務(wù)器崩潰退出而導(dǎo)致的數(shù)據(jù)不一致問(wèn)題，因此ZooKeeper中又添加了崩潰恢復(fù)模式來(lái)解決這個(gè)問(wèn)題。

崩潰恢復(fù)

當(dāng)Leader服務(wù)器出現(xiàn)崩潰退出或機(jī)器重啟，亦或是集群中不存在半數(shù)以上的服務(wù)器與Leader服務(wù)器保持正常通信時(shí)，在重新開(kāi)始新的一輪原子廣播事務(wù)操作之前，此時(shí)所有節(jié)點(diǎn)都會(huì)使用崩潰恢復(fù)協(xié)議來(lái)使彼此達(dá)到一個(gè)一致的狀態(tài)。

崩潰恢復(fù)過(guò)程需要確保那些已經(jīng)在Leader服務(wù)器上提交的事務(wù)最終被所有的事務(wù)提交。

假設(shè)一個(gè)事務(wù)中Leader服務(wù)器（server2）上被提交了，并且已經(jīng)得到了過(guò)半Follower服務(wù)器的ACK反饋，但是在它將Commit消息發(fā)送給所有的Follower機(jī)器之前，Leader服務(wù)器就掛掉了，如下圖：

確保那些已經(jīng)在Leader服務(wù)器上提交的事務(wù)最終被所有的事務(wù)提交

從上圖可以看到，部分的節(jié)點(diǎn)收到了commit請(qǐng)求并進(jìn)行了提交，而有一部分Leader還沒(méi)來(lái)得及發(fā)送就已經(jīng)崩潰了。針對(duì)這種情況，崩潰恢復(fù)必須要確保該事務(wù)最終能夠在所有的服務(wù)器上都被提交成功，否則將會(huì)出現(xiàn)數(shù)據(jù)不一致的情況。所以在重新選舉的時(shí)候，必定會(huì)選取ZXID最大的節(jié)點(diǎn)來(lái)確保其保留了最新的事件。

崩潰恢復(fù)過(guò)程需要確保丟棄那些只在Leader服務(wù)器上被提出的事務(wù)。

如果Leader服務(wù)器在提交了一個(gè)事務(wù)之后，還沒(méi)來(lái)得及廣播發(fā)送commit就已經(jīng)崩潰推出了，從而導(dǎo)致集群中的其他服務(wù)器都沒(méi)有收到這個(gè)事務(wù)提議。當(dāng)原先的Leader節(jié)點(diǎn)故障恢復(fù)后，再次以Follower的角色加入集群后，此時(shí)就因?yàn)橹挥兴瓿闪耸聞?wù)提交，而產(chǎn)生了數(shù)據(jù)不一致的情況，如下圖：

確保丟棄那些只在Leader服務(wù)器上被提出的事務(wù)

針對(duì)這種情況，我們需要讓server2在故障恢復(fù)后能夠丟棄這些只在它這個(gè)節(jié)點(diǎn)上提出的事務(wù)，來(lái)確保數(shù)據(jù)一致。

為了能夠滿足上述的兩個(gè)要求，所以ZooKeeper讓Leader選舉算法保證新選舉出來(lái)的Leader服務(wù)器擁有集群中所有機(jī)器最高的事務(wù)編號(hào)（ZXID最大），那么這就肯定能夠保證新選舉出來(lái)的Leader一定具有所有已經(jīng)提交的提案，此時(shí)新的Leader就會(huì)將事務(wù)日志中尚未提交的消息同步到各個(gè)服務(wù)器中。

總結(jié)

以上是生活随笔為你收集整理的ZooKeeper ZAB协议：崩溃恢复、消息广播的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。