轉(zhuǎn)自http://www.reibang.com/p/ba8e17b51f12

一致性協(xié)議有很多種淀弹，比如 Paxos丹壕，Raft，2PC薇溃，3PC等等菌赖，在這講一種協(xié)議，ZAB 協(xié)議沐序，該協(xié)議應(yīng)該是所有一致性協(xié)議中生產(chǎn)環(huán)境中應(yīng)用最多的了琉用。為什么？因?yàn)樗菫?Zookeeper 設(shè)計(jì)的分布式一致性協(xié)議策幼！

1. 什么是 ZAB 協(xié)議邑时？ ZAB 協(xié)議介紹

1. ZAB 協(xié)議全稱：Zookeeper Atomic Broadcast（Zookeeper 原子廣播協(xié)議）。
2. Zookeeper 是一個(gè)為分布式應(yīng)用提供高效且可靠的分布式協(xié)調(diào)服務(wù)垄惧。在解決分布式一致性方面刁愿，Zookeeper 并沒(méi)有使用 Paxos 绰寞，而是采用了 ZAB 協(xié)議到逊。
3. ZAB 協(xié)議定義：ZAB 協(xié)議是為分布式協(xié)調(diào)服務(wù) Zookeeper 專門設(shè)計(jì)的一種支持****崩潰恢復(fù)和原子廣播協(xié)議铣口。下面我們會(huì)重點(diǎn)講這兩個(gè)東西。
4. 基于該協(xié)議觉壶，Zookeeper 實(shí)現(xiàn)了一種主備模式的系統(tǒng)架構(gòu)來(lái)保持集群中各個(gè)副本之間 數(shù)據(jù)一致性脑题。具體如下圖所示：

image

上圖顯示了 Zookeeper 如何處理集群中的數(shù)據(jù)。所有客戶端寫(xiě)入數(shù)據(jù)都是寫(xiě)入到 主進(jìn)程（稱為 Leader）中铜靶，然后叔遂，由 Leader 復(fù)制到備份進(jìn)程（稱為 Follower）中。從而保證數(shù)據(jù)一致性争剿。從設(shè)計(jì)上看已艰，和 Raft 類似。

那么復(fù)制過(guò)程又是如何的呢蚕苇？

復(fù)制過(guò)程類似 2PC哩掺，ZAB 只需要 Follower 有一半以上返回 Ack 信息就可以執(zhí)行提交，大大減小了同步阻塞涩笤。也提高了可用性嚼吞。

簡(jiǎn)單介紹完，開(kāi)始重點(diǎn)介紹消息廣播和崩潰恢復(fù)蹬碧。整個(gè) Zookeeper 就是在這兩個(gè)模式之間切換舱禽。 簡(jiǎn)而言之，當(dāng) Leader 服務(wù)可以正常使用恩沽，就進(jìn)入消息廣播模式誊稚，當(dāng) Leader 不可用時(shí)，則進(jìn)入崩潰恢復(fù)模式飒筑。

2. 消息廣播

ZAB 協(xié)議的消息廣播過(guò)程使用的是一個(gè)原子廣播協(xié)議片吊，類似一個(gè) 二階段提交過(guò)程。對(duì)于客戶端發(fā)送的寫(xiě)請(qǐng)求协屡，全部由 Leader 接收俏脊，Leader 將請(qǐng)求封裝成一個(gè)事務(wù) Proposal，將其發(fā)送給所有 Follwer 肤晓，然后爷贫，根據(jù)所有 Follwer 的反饋，如果超過(guò)半數(shù)成功響應(yīng)补憾，則執(zhí)行 commit 操作（先提交自己漫萄，再發(fā)送 commit 給所有 Follwer）。

基本上盈匾，整個(gè)廣播流程分為 3 步驟：

1腾务、將數(shù)據(jù)都復(fù)制到 Follwer 中

image

2、等待 Follwer 回應(yīng) Ack削饵，最低超過(guò)半數(shù)即成功

image

3岩瘦、當(dāng)超過(guò)半數(shù)成功回應(yīng)未巫，則執(zhí)行 commit ，同時(shí)提交自己

image

通過(guò)以上 3 個(gè)步驟启昧，就能夠保持集群之間數(shù)據(jù)的一致性叙凡。實(shí)際上，在 Leader 和 Follwer 之間還有一個(gè)消息隊(duì)列密末，用來(lái)解耦他們之間的耦合握爷，避免同步，實(shí)現(xiàn)異步解耦严里。

還有一些細(xì)節(jié)：

1. Leader 在收到客戶端請(qǐng)求之后新啼，會(huì)將這個(gè)請(qǐng)求封裝成一個(gè)事務(wù)，并給這個(gè)事務(wù)分配一個(gè)全局遞增的唯一 ID刹碾，稱為事務(wù)ID（ZXID）师抄，ZAB 兮協(xié)議需要保證事務(wù)的順序，因此必須將每一個(gè)事務(wù)按照 ZXID 進(jìn)行先后排序然后處理教硫。
2. 在 Leader 和 Follwer 之間還有一個(gè)消息隊(duì)列叨吮，用來(lái)解耦他們之間的耦合，解除同步阻塞瞬矩。
3. zookeeper集群中為保證任何所有進(jìn)程能夠有序的順序執(zhí)行茶鉴，只能是 Leader 服務(wù)器接受寫(xiě)請(qǐng)求，即使是 Follower 服務(wù)器接受到客戶端的請(qǐng)求景用，也會(huì)轉(zhuǎn)發(fā)到 Leader 服務(wù)器進(jìn)行處理涵叮。
4. 實(shí)際上，這是一種簡(jiǎn)化版本的 2PC伞插，不能解決單點(diǎn)問(wèn)題割粮。等會(huì)我們會(huì)講述 ZAB 如何解決單點(diǎn)問(wèn)題（即 Leader 崩潰問(wèn)題）。

3. 崩潰恢復(fù)

剛剛我們說(shuō)消息廣播過(guò)程中媚污，Leader 崩潰怎么辦舀瓢？還能保證數(shù)據(jù)一致嗎？如果 Leader 先本地提交了耗美，然后 commit 請(qǐng)求沒(méi)有發(fā)送出去京髓，怎么辦？

實(shí)際上商架，當(dāng) Leader 崩潰堰怨，即進(jìn)入我們開(kāi)頭所說(shuō)的崩潰恢復(fù)模式（崩潰即：Leader 失去與過(guò)半 Follwer 的聯(lián)系）。下面來(lái)詳細(xì)講述蛇摸。

假設(shè)1：Leader 在復(fù)制數(shù)據(jù)給所有 Follwer 之后崩潰备图，怎么辦？ 假設(shè)2：Leader 在收到 Ack 并提交了自己，同時(shí)發(fā)送了部分 commit 出去之后崩潰怎么辦揽涮？

針對(duì)這些問(wèn)題砸烦，ZAB 定義了 2 個(gè)原則：

1. ZAB 協(xié)議確保那些已經(jīng)在 Leader 提交的事務(wù)最終會(huì)被所有服務(wù)器提交。
2. ZAB 協(xié)議確保丟棄那些只在 Leader 提出/復(fù)制绞吁，但沒(méi)有提交的事務(wù)。

所以唬格，ZAB 設(shè)計(jì)了下面這樣一個(gè)選舉算法：能夠確保提交已經(jīng)被 Leader 提交的事務(wù)家破，同時(shí)丟棄已經(jīng)被跳過(guò)的事務(wù)。

針對(duì)這個(gè)要求购岗，如果讓 Leader 選舉算法能夠保證新選舉出來(lái)的 Leader 服務(wù)器擁有集群總所有機(jī)器編號(hào)（即 ZXID 最大）的事務(wù)汰聋，那么就能夠保證這個(gè)新選舉出來(lái)的 Leader 一定具有所有已經(jīng)提交的提案。 而且這么做有一個(gè)好處是：可以省去 Leader 服務(wù)器檢查事務(wù)的提交和丟棄工作的這一步操作喊积。

image

這樣烹困，我們剛剛假設(shè)的兩個(gè)問(wèn)題便能夠解決。假設(shè) 1 最終會(huì)丟棄調(diào)用沒(méi)有提交的數(shù)據(jù)乾吻，假設(shè) 2 最終會(huì)同步所有服務(wù)器的數(shù)據(jù)髓梅。這個(gè)時(shí)候，就引出了一個(gè)問(wèn)題绎签，如何同步枯饿？

4. 數(shù)據(jù)同步

當(dāng)崩潰恢復(fù)之后，需要在正式工作之前（接收客戶端請(qǐng)求）诡必，Leader 服務(wù)器首先確認(rèn)事務(wù)是否都已經(jīng)被過(guò)半的 Follwer 提交了奢方，即是否完成了數(shù)據(jù)同步。目的是為了保持?jǐn)?shù)據(jù)一致爸舒。

當(dāng)所有的 Follwer 服務(wù)器都成功同步之后蟋字，Leader 會(huì)將這些服務(wù)器加入到可用服務(wù)器列表中。

實(shí)際上扭勉，Leader 服務(wù)器處理或丟棄事務(wù)都是依賴著 ZXID 的鹊奖，那么這個(gè) ZXID 如何生成呢？

答：在 ZAB 協(xié)議的事務(wù)編號(hào) ZXID 設(shè)計(jì)中涂炎，ZXID 是一個(gè) 64 位的數(shù)字嫉入，其中低 32 位可以看作是一個(gè)簡(jiǎn)單的遞增的計(jì)數(shù)器，針對(duì)客戶端的每一個(gè)事務(wù)請(qǐng)求璧尸，Leader 都會(huì)產(chǎn)生一個(gè)新的事務(wù) Proposal 并對(duì)該計(jì)數(shù)器進(jìn)行 + 1 操作咒林。

而高 32 位則代表了 Leader 服務(wù)器上取出本地日志中最大事務(wù) Proposal 的 ZXID，并從該 ZXID 中解析出對(duì)應(yīng)的 epoch 值爷光，然后再對(duì)這個(gè)值加一垫竞。

image

高 32 位代表了每代 Leader 的唯一性，低 32 代表了每代 Leader 中事務(wù)的唯一性。同時(shí)欢瞪，也能讓 Follwer 通過(guò)高 32 位識(shí)別不同的 Leader活烙。簡(jiǎn)化了數(shù)據(jù)恢復(fù)流程。

基于這樣的策略：當(dāng) Follower 鏈接上 Leader 之后遣鼓，Leader 服務(wù)器會(huì)根據(jù)自己服務(wù)器上最后被提交的 ZXID 和 Follower 上的 ZXID 進(jìn)行比對(duì)啸盏，比對(duì)結(jié)果要么回滾，要么和 Leader 同步骑祟。

5. 總結(jié)

到了總結(jié)的時(shí)刻了回懦。

ZAB 協(xié)議和我們之前看的 Raft 協(xié)議實(shí)際上是有相似之處的，比如都有一個(gè) Leader次企，用來(lái)保證一致性（Paxos 并沒(méi)有使用 Leader 機(jī)制保證一致性）怯晕。再有采取過(guò)半即成功的機(jī)制保證服務(wù)可用（實(shí)際上 Paxos 和 Raft 都是這么做的）。

ZAB 讓整個(gè) Zookeeper 集群在兩個(gè)模式之間轉(zhuǎn)換缸棵，消息廣播和崩潰恢復(fù)舟茶，消息廣播可以說(shuō)是一個(gè)簡(jiǎn)化版本的 2PC，通過(guò)崩潰恢復(fù)解決了 2PC 的單點(diǎn)問(wèn)題堵第，通過(guò)隊(duì)列解決了 2PC 的同步阻塞問(wèn)題吧凉。

而支持崩潰恢復(fù)后數(shù)據(jù)準(zhǔn)確性的就是數(shù)據(jù)同步了，數(shù)據(jù)同步基于事務(wù)的 ZXID 的唯一性來(lái)保證踏志。通過(guò) + 1 操作可以辨別事務(wù)的先后順序客燕。關(guān)于 ZAB 協(xié)議就介紹到這里，篇幅有限狰贯，難免疏漏也搓。

作者：若丨寒
鏈接：http://www.reibang.com/p/ba8e17b51f12
來(lái)源：簡(jiǎn)書(shū)
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請(qǐng)聯(lián)系作者獲得授權(quán)涵紊，非商業(yè)轉(zhuǎn)載請(qǐng)注明出處傍妒。