一致性協(xié)議有很多種爆捞，比如 Paxos奉瘤，Raft，2PC，3PC等等盗温，今天我們講一種協(xié)議藕赞，ZAB 協(xié)議，該協(xié)議應(yīng)該是所有一致性協(xié)議中生產(chǎn)環(huán)境中應(yīng)用最多的了卖局。為什么呢斧蜕？因?yàn)樗菫?Zookeeper 設(shè)計(jì)的分布式一致性協(xié)議！
一砚偶、什么是 ZAB 協(xié)議批销？ ZAB 協(xié)議介紹
1、ZAB 協(xié)議全稱：Zookeeper Atomic Broadcast（Zookeeper 原子廣播協(xié)議）染坯。
2芭梯、Zookeeper 是一個(gè)為分布式應(yīng)用提供高效且可靠的分布式協(xié)調(diào)服務(wù)次乓。在解決分布式一致性方面，Zookeeper 并沒有使用 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)來保持集群中各個(gè)副本之間 數(shù)據(jù)一致性镣奋。具體如下圖所示：
上圖顯示了 Zookeeper 如何處理集群中的數(shù)據(jù)。所有客戶端寫入數(shù)據(jù)都是寫入到 主進(jìn)程（稱為 Leader）中怀愧，然后侨颈，由 Leader 復(fù)制到備份進(jìn)程（稱為 Follower）中。從而保證數(shù)據(jù)一致性芯义。從設(shè)計(jì)上看肛搬，和 Raft 類似。
那么復(fù)制過程又是如何的呢毕贼？
復(fù)制過程類似 2PC温赔，ZAB 只需要 Follower 有一半以上返回 Ack 信息就可以執(zhí)行提交，大大減小了同步阻塞鬼癣。也提高了可用性陶贼。
簡單介紹完，開始重點(diǎn)介紹 消息廣播 和 崩潰恢復(fù)待秃。整個(gè) Zookeeper 就是在這兩個(gè)模式之間切換拜秧。 簡而言之，當(dāng) Leader 服務(wù)可以正常使用章郁，就進(jìn)入消息廣播模式枉氮，當(dāng) Leader 不可用時(shí)志衍，則進(jìn)入崩潰恢復(fù)模式。
二聊替、消息廣播
ZAB 協(xié)議的消息廣播過程使用的是一個(gè)原子廣播協(xié)議楼肪，類似一個(gè) 二階段提交過程。對于客戶端發(fā)送的寫請求惹悄，全部由 Leader 接收春叫，Leader 將請求封裝成一個(gè)事務(wù) Proposal，將其發(fā)送給所有 Follwer 泣港，然后暂殖，根據(jù)所有 Follwer 的反饋，如果超過半數(shù)成功響應(yīng)当纱，則執(zhí)行 commit 操作（先提交自己呛每，再發(fā)送 commit 給所有 Follwer）。
基本上坡氯，整個(gè)廣播流程分為 3 步驟：
1莉给、將數(shù)據(jù)都復(fù)制到 Follwer 中
2、等待 Follwer 回應(yīng) Ack廉沮，最低超過半數(shù)即成功
3、當(dāng)超過半數(shù)成功回應(yīng)徐矩，則執(zhí)行 commit 滞时，同時(shí)提交自己
通過以上 3 個(gè)步驟，就能夠保持集群之間數(shù)據(jù)的一致性滤灯。實(shí)際上坪稽，在 Leader 和 Follwer 之間還有一個(gè)消息隊(duì)列，用來解耦他們之間的耦合鳞骤，避免同步窒百，實(shí)現(xiàn)異步解耦。
還有一些細(xì)節(jié)：
1豫尽、Leader 在收到客戶端請求之后篙梢，會(huì)將這個(gè)請求封裝成一個(gè)事務(wù)，并給這個(gè)事務(wù)分配一個(gè)全局遞增的唯一 ID美旧，稱為事務(wù)ID（ZXID）渤滞，ZAB 兮協(xié)議需要保證事務(wù)的順序，因此必須將每一個(gè)事務(wù)按照 ZXID 進(jìn)行先后排序然后處理榴嗅。
2妄呕、在 Leader 和 Follwer 之間還有一個(gè)消息隊(duì)列，用來解耦他們之間的耦合嗽测，解除同步阻塞绪励。
3、zookeeper集群中為保證任何所有進(jìn)程能夠有序的順序執(zhí)行，只能是 Leader 服務(wù)器接受寫請求疏魏，即使是 Follower 服務(wù)器接受到客戶端的請求停做，也會(huì)轉(zhuǎn)發(fā)到 Leader 服務(wù)器進(jìn)行處理。
4蠢护、實(shí)際上雅宾，這是一種簡化版本的 2PC，不能解決單點(diǎn)問題葵硕。等會(huì)我們會(huì)講述 ZAB 如何解決單點(diǎn)問題（即 Leader 崩潰問題）眉抬。
三、崩潰恢復(fù)
剛剛我們說消息廣播過程中懈凹，Leader 崩潰怎么辦蜀变？還能保證數(shù)據(jù)一致嗎？如果 Leader 先本地提交了介评，然后 commit 請求沒有發(fā)送出去库北，怎么辦？
實(shí)際上们陆，當(dāng) Leader 崩潰寒瓦，即進(jìn)入我們開頭所說的崩潰恢復(fù)模式（崩潰即：Leader 失去與過半 Follwer 的聯(lián)系）。下面來詳細(xì)講述坪仇。
假設(shè)1：Leader 在復(fù)制數(shù)據(jù)給所有 Follwer 之后崩潰杂腰，怎么辦？
假設(shè)2：Leader 在收到 Ack 并提交了自己椅文，同時(shí)發(fā)送了部分 commit 出去之后崩潰怎么辦喂很？
針對這些問題，ZAB 定義了 2 個(gè)原則：
1皆刺、ZAB 協(xié)議確保那些已經(jīng)在 Leader 提交的事務(wù)最終會(huì)被所有服務(wù)器提交少辣。
2、ZAB 協(xié)議確保丟棄那些只在 Leader 提出/復(fù)制羡蛾，但沒有提交的事務(wù)漓帅。
所以，ZAB 設(shè)計(jì)了下面這樣一個(gè)選舉算法：能夠確保提交已經(jīng)被 Leader 提交的事務(wù)痴怨，同時(shí)丟棄已經(jīng)被跳過的事務(wù)煎殷。
針對這個(gè)要求，如果讓 Leader 選舉算法能夠保證新選舉出來的 Leader 服務(wù)器擁有集群總所有機(jī)器編號(hào)（即 ZXID 最大）的事務(wù)腿箩，那么就能夠保證這個(gè)新選舉出來的 Leader 一定具有所有已經(jīng)提交的提案豪直。
而且這么做有一個(gè)好處是：可以省去 Leader 服務(wù)器檢查事務(wù)的提交和丟棄工作的這一步操作。
這樣珠移，我們剛剛假設(shè)的兩個(gè)問題便能夠解決弓乙。假設(shè) 1 最終會(huì)丟棄調(diào)用沒有提交的數(shù)據(jù)末融，假設(shè) 2 最終會(huì)同步所有服務(wù)器的數(shù)據(jù)。這個(gè)時(shí)候暇韧，就引出了一個(gè)問題勾习，如何同步？
四懈玻、數(shù)據(jù)同步
當(dāng)崩潰恢復(fù)之后巧婶，需要在正式工作之前（接收客戶端請求），Leader 服務(wù)器首先確認(rèn)事務(wù)是否都已經(jīng)被過半的 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è)簡單的遞增的計(jì)數(shù)器丈莺，針對客戶端的每一個(gè)事務(wù)請求，Leader 都會(huì)產(chǎn)生一個(gè)新的事務(wù) Proposal 并對該計(jì)數(shù)器進(jìn)行 + 1 操作送丰。
而高 32 位則代表了 Leader 服務(wù)器上取出本地日志中最大事務(wù) Proposal 的 ZXID缔俄，并從該 ZXID 中解析出對應(yīng)的 epoch 值，然后再對這個(gè)值加一蚪战。
高 32 位代表了每代 Leader 的唯一性，低 32 代表了每代 Leader 中事務(wù)的唯一性铐懊。同時(shí)邀桑，也能讓 Follwer 通過高 32 位識(shí)別不同的 Leader。簡化了數(shù)據(jù)恢復(fù)流程科乎。
基于這樣的策略：當(dāng) Follower 鏈接上 Leader 之后壁畸，Leader 服務(wù)器會(huì)根據(jù)自己服務(wù)器上最后被提交的 ZXID 和 Follower 上的 ZXID 進(jìn)行比對，比對結(jié)果要么回滾茅茂，要么和 Leader 同步捏萍。
五、總結(jié)
到了總結(jié)的時(shí)刻了空闲。
ZAB 協(xié)議和我們之前看的 Raft 協(xié)議實(shí)際上是有相似之處的令杈，比如都有一個(gè) Leader，用來保證一致性（Paxos 并沒有使用 Leader 機(jī)制保證一致性）碴倾。再有采取過半即成功的機(jī)制保證服務(wù)可用（實(shí)際上 Paxos 和 Raft 都是這么做的）逗噩。
ZAB 讓整個(gè) Zookeeper 集群在兩個(gè)模式之間轉(zhuǎn)換掉丽，消息廣播和崩潰恢復(fù)，消息廣播可以說是一個(gè)簡化版本的 2PC异雁，通過崩潰恢復(fù)解決了 2PC 的單點(diǎn)問題捶障，通過隊(duì)列解決了 2PC 的同步阻塞問題。
而支持崩潰恢復(fù)后數(shù)據(jù)準(zhǔn)確性的就是數(shù)據(jù)同步了纲刀，數(shù)據(jù)同步基于事務(wù)的 ZXID 的唯一性來保證项炼。通過 + 1 操作可以辨別事務(wù)的先后順序。
歡迎工作一到五年的Java工程師朋友們加入Java高并發(fā)： 957734884示绊，
群內(nèi)提供免費(fèi)的Java架構(gòu)學(xué)習(xí)資料（里面有高可用锭部、高并發(fā)、高性能及分布式耻台、Jvm性能調(diào)優(yōu)空免、Spring源碼，MyBatis盆耽，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個(gè)知識(shí)點(diǎn)的架構(gòu)資料）合理利用自己每一分每一秒的時(shí)間來學(xué)習(xí)提升自己蹋砚，不要再用"沒有時(shí)間“來掩飾自己思想上的懶惰！趁年輕摄杂，使勁拼坝咐，給未來的自己一個(gè)交代！
