一致性協(xié)議有很多種兄朋，比如 Paxos存炮，Raft，2PC蜈漓，3PC等等穆桂，今天我們講一種協(xié)議，ZAB 協(xié)議融虽，該協(xié)議應該是所有一致性協(xié)議中生產(chǎn)環(huán)境中應用最多的了享完。為什么呢？因為他是為 Zookeeper 設計的分布式一致性協(xié)議有额！
一般又、什么是 ZAB 協(xié)議？ ZAB 協(xié)議介紹
1巍佑、ZAB 協(xié)議全稱：Zookeeper Atomic Broadcast（Zookeeper 原子廣播協(xié)議）茴迁。
2、Zookeeper 是一個為分布式應用提供高效且可靠的分布式協(xié)調(diào)服務萤衰。在解決分布式一致性方面堕义，Zookeeper 并沒有使用 Paxos ，而是采用了 ZAB 協(xié)議脆栋。
3倦卖、ZAB 協(xié)議定義：ZAB 協(xié)議是為分布式協(xié)調(diào)服務 Zookeeper 專門設計的一種支持 崩潰恢復 和 原子廣播 協(xié)議。下面我們會重點講這兩個東西椿争。
4怕膛、基于該協(xié)議，Zookeeper 實現(xiàn)了一種 主備模式 的系統(tǒng)架構(gòu)來保持集群中各個副本之間 數(shù)據(jù)一致性秦踪。具體如下圖所示：
上圖顯示了 Zookeeper 如何處理集群中的數(shù)據(jù)褐捻。所有客戶端寫入數(shù)據(jù)都是寫入到 主進程（稱為 Leader）中掸茅，然后，由 Leader 復制到備份進程（稱為 Follower）中柠逞。從而保證數(shù)據(jù)一致性倦蚪。從設計上看，和 Raft 類似边苹。
那么復制過程又是如何的呢陵且？
復制過程類似 2PC，ZAB 只需要 Follower 有一半以上返回 Ack 信息就可以執(zhí)行提交个束，大大減小了同步阻塞慕购。也提高了可用性。
簡單介紹完茬底，開始重點介紹 消息廣播 和 崩潰恢復沪悲。整個 Zookeeper 就是在這兩個模式之間切換。?簡而言之阱表，當 Leader 服務可以正常使用殿如，就進入消息廣播模式，當 Leader 不可用時最爬，則進入崩潰恢復模式涉馁。
二、消息廣播
ZAB 協(xié)議的消息廣播過程使用的是一個原子廣播協(xié)議爱致，類似一個?二階段提交過程烤送。對于客戶端發(fā)送的寫請求，全部由 Leader 接收糠悯，Leader 將請求封裝成一個事務 Proposal帮坚，將其發(fā)送給所有 Follwer ，然后互艾，根據(jù)所有 Follwer 的反饋试和，如果超過半數(shù)成功響應，則執(zhí)行 commit 操作（先提交自己纫普，再發(fā)送 commit 給所有 Follwer）阅悍。
基本上，整個廣播流程分為 3 步驟：
1局嘁、將數(shù)據(jù)都復制到 Follwer 中
2溉箕、等待 Follwer 回應 Ack，最低超過半數(shù)即成功
3悦昵、當超過半數(shù)成功回應，則執(zhí)行 commit 晌畅，同時提交自己
通過以上 3 個步驟但指，就能夠保持集群之間數(shù)據(jù)的一致性。實際上，在 Leader 和 Follwer 之間還有一個消息隊列棋凳，用來解耦他們之間的耦合拦坠，避免同步，實現(xiàn)異步解耦剩岳。
還有一些細節(jié)：
1贞滨、Leader 在收到客戶端請求之后，會將這個請求封裝成一個事務拍棕，并給這個事務分配一個全局遞增的唯一 ID晓铆，稱為事務ID（ZXID），ZAB 兮協(xié)議需要保證事務的順序绰播，因此必須將每一個事務按照 ZXID 進行先后排序然后處理骄噪。
2、在 Leader 和 Follwer 之間還有一個消息隊列蠢箩，用來解耦他們之間的耦合链蕊，解除同步阻塞。
3谬泌、zookeeper集群中為保證任何所有進程能夠有序的順序執(zhí)行滔韵，只能是 Leader 服務器接受寫請求，即使是 Follower 服務器接受到客戶端的請求掌实，也會轉(zhuǎn)發(fā)到 Leader 服務器進行處理奏属。
4、實際上潮峦，這是一種簡化版本的 2PC囱皿，不能解決單點問題。等會我們會講述 ZAB 如何解決單點問題（即 Leader 崩潰問題）忱嘹。
三嘱腥、崩潰恢復
剛剛我們說消息廣播過程中，Leader 崩潰怎么辦拘悦？還能保證數(shù)據(jù)一致嗎齿兔？如果 Leader 先本地提交了，然后 commit 請求沒有發(fā)送出去础米，怎么辦分苇？
實際上，當 Leader 崩潰屁桑，即進入我們開頭所說的崩潰恢復模式（崩潰即：Leader 失去與過半 Follwer 的聯(lián)系）医寿。下面來詳細講述。
假設1：Leader 在復制數(shù)據(jù)給所有 Follwer 之后崩潰蘑斧，怎么辦靖秩？
假設2：Leader 在收到 Ack 并提交了自己须眷，同時發(fā)送了部分 commit 出去之后崩潰怎么辦？
針對這些問題沟突，ZAB 定義了 2 個原則：
1花颗、ZAB 協(xié)議確保那些已經(jīng)在 Leader 提交的事務最終會被所有服務器提交。
2惠拭、ZAB 協(xié)議確保丟棄那些只在 Leader 提出/復制扩劝，但沒有提交的事務。
所以职辅，ZAB 設計了下面這樣一個選舉算法：能夠確保提交已經(jīng)被 Leader 提交的事務棒呛，同時丟棄已經(jīng)被跳過的事務。
針對這個要求罐农，如果讓 Leader 選舉算法能夠保證新選舉出來的 Leader 服務器擁有集群總所有機器編號（即 ZXID 最大）的事務条霜，那么就能夠保證這個新選舉出來的 Leader 一定具有所有已經(jīng)提交的提案。
而且這么做有一個好處是：可以省去 Leader 服務器檢查事務的提交和丟棄工作的這一步操作涵亏。
這樣宰睡，我們剛剛假設的兩個問題便能夠解決。假設 1 最終會丟棄調(diào)用沒有提交的數(shù)據(jù)气筋，假設 2 最終會同步所有服務器的數(shù)據(jù)拆内。這個時候，就引出了一個問題宠默，如何同步麸恍？
四、數(shù)據(jù)同步
當崩潰恢復之后搀矫，需要在正式工作之前（接收客戶端請求）抹沪，Leader 服務器首先確認事務是否都已經(jīng)被過半的 Follwer 提交了，即是否完成了數(shù)據(jù)同步瓤球。目的是為了保持數(shù)據(jù)一致融欧。
當所有的 Follwer 服務器都成功同步之后，Leader 會將這些服務器加入到可用服務器列表中卦羡。
實際上噪馏，Leader 服務器處理或丟棄事務都是依賴著 ZXID 的，那么這個 ZXID 如何生成呢绿饵？
答：在 ZAB 協(xié)議的事務編號 ZXID 設計中欠肾，ZXID 是一個 64 位的數(shù)字，其中低 32 位可以看作是一個簡單的遞增的計數(shù)器拟赊，針對客戶端的每一個事務請求刺桃，Leader 都會產(chǎn)生一個新的事務 Proposal 并對該計數(shù)器進行 + 1 操作。
而高 32 位則代表了 Leader 服務器上取出本地日志中最大事務 Proposal 的 ZXID要门，并從該 ZXID 中解析出對應的 epoch 值虏肾，然后再對這個值加一廓啊。
高 32 位代表了每代 Leader 的唯一性欢搜，低 32 代表了每代 Leader 中事務的唯一性封豪。同時，也能讓 Follwer 通過高 32 位識別不同的 Leader炒瘟。簡化了數(shù)據(jù)恢復流程吹埠。
基于這樣的策略：當 Follower 鏈接上 Leader 之后，Leader 服務器會根據(jù)自己服務器上最后被提交的 ZXID 和 Follower 上的 ZXID 進行比對疮装，比對結(jié)果要么回滾缘琅，要么和 Leader 同步。
五廓推、總結(jié)
到了總結(jié)的時刻了刷袍。
ZAB 協(xié)議和我們之前看的 Raft 協(xié)議實際上是有相似之處的，比如都有一個 Leader樊展，用來保證一致性（Paxos 并沒有使用 Leader 機制保證一致性）呻纹。再有采取過半即成功的機制保證服務可用（實際上 Paxos 和 Raft 都是這么做的）。
ZAB 讓整個 Zookeeper 集群在兩個模式之間轉(zhuǎn)換专缠，消息廣播和崩潰恢復雷酪，消息廣播可以說是一個簡化版本的 2PC，通過崩潰恢復解決了 2PC 的單點問題涝婉，通過隊列解決了 2PC 的同步阻塞問題哥力。
而支持崩潰恢復后數(shù)據(jù)準確性的就是數(shù)據(jù)同步了，數(shù)據(jù)同步基于事務的 ZXID 的唯一性來保證墩弯。通過 + 1 操作可以辨別事務的先后順序吩跋。
覺得不錯請點贊支持，歡迎留言或進我的個人群855801563領(lǐng)取【架構(gòu)資料專題目合集90期】渔工、【BATJTMD大廠JAVA面試真題1000+】锌钮，本群專用于學習交流技術(shù)、分享面試機會涨缚，拒絕廣告轧粟，我也會在群內(nèi)不定期答題、探討脓魏。
