1.什么是ZAB協(xié)議?

支持崩潰恢復(fù)的原子廣播協(xié)議，主要用于實(shí)現(xiàn)數(shù)據(jù)一致性

1. ZAB 協(xié)議全稱：Zookeeper Atomic Broadcast（Zookeeper 原子廣播協(xié)議）。

2. 基于該協(xié)議，zookeeper中實(shí)現(xiàn)了一種主備模式 的系統(tǒng)架構(gòu)來保持集群中各個(gè)副本之間數(shù)據(jù)一致性

其實(shí)zookeeper的就在崩潰恢復(fù)和消息廣播這兩個(gè)模式之間進(jìn)行切換。當(dāng) Leader 服務(wù)可以正常使用，就進(jìn)入消息廣播模式，當(dāng) Leader 不可用時(shí)，則進(jìn)入崩潰恢復(fù)模式。

主備模式

主備模式簡(jiǎn)圖

在上圖中有多個(gè)客戶端向Leader節(jié)點(diǎn)發(fā)起寫入數(shù)據(jù)操作，Leader節(jié)點(diǎn)接收到數(shù)據(jù)之后將數(shù)據(jù)備份到多個(gè)Slaver中，從而保證數(shù)據(jù)一致性。

原子廣播

原子廣播圖解

1. 客戶端首先向zookeeper任意節(jié)點(diǎn)發(fā)起寫請(qǐng)求（事務(wù)）。
2. 如果接收的節(jié)點(diǎn)是Fellower/Observer類型，就將請(qǐng)求轉(zhuǎn)發(fā)給Leader節(jié)點(diǎn)。
3. Leader節(jié)點(diǎn)接收到消息之后對(duì)消息進(jìn)行處理
??1. Leader節(jié)點(diǎn)對(duì)每條消息（事務(wù)）生成一個(gè)對(duì)應(yīng)的zxid（全局唯一，遞增）
??2. 將帶有zxid的消息包裝成一個(gè)proposal轉(zhuǎn)發(fā)給所有的Follower節(jié)點(diǎn)。
4. Follower將proposal這個(gè)事務(wù)寫到磁盤，將結(jié)果（ack）返回給leader。
5. Leader節(jié)點(diǎn)統(tǒng)計(jì)ack數(shù)量。
??1.如果有一半以上的節(jié)點(diǎn)返回成功，則向所有的Follower節(jié)點(diǎn)（包括自己）發(fā)送commit消息提交事務(wù)，并且給Observer發(fā)送INFORM消息。
??2.如果ack數(shù)量小于一半則發(fā)送rollback消息進(jìn)行事務(wù)回滾。
6. 最后返回給客戶端

簡(jiǎn)單解釋
其實(shí)一個(gè)寫請(qǐng)求就相當(dāng)于mysql的一個(gè)事務(wù)
我們將事務(wù)發(fā)送到每個(gè)Follow節(jié)點(diǎn)上，節(jié)點(diǎn)如果成功操作就返回ack信息
只要成功操作節(jié)點(diǎn)的數(shù)量大于一半就將事務(wù)提交（commit）
否則的話就將事務(wù)進(jìn)行回滾（rollback）

崩潰恢復(fù)

實(shí)際上，Leader 服務(wù)器處理或丟棄事務(wù)都是依賴著 ZXID 的，那么這個(gè) ZXID 如何生成呢？
ZXID（64位）：低32位表示消息計(jì)數(shù)器（自增），高32位（epoch編號(hào)），每次leader得到一個(gè)事務(wù)都會(huì)為該事務(wù)生成一個(gè)ZXID
Epoch（32位）：每產(chǎn)生一個(gè)新的leader,那么epoch會(huì)+1

ZXID

將Leader節(jié)點(diǎn)宕機(jī)或者失去了過半的follower節(jié)點(diǎn)的聯(lián)系時(shí)就進(jìn)入崩潰恢復(fù)模式
崩潰存在以下兩種狀況

1. Leader 在收到 Ack 并提交了自己，同時(shí)發(fā)送了部分 commit 出去之后崩潰

發(fā)出部分commit

因?yàn)槊看翁峤坏氖聞?wù)都有一個(gè)zxid（全局唯一，遞增），因此我們只需要找出所有機(jī)器內(nèi)zxid最大的事務(wù)（既該事務(wù)是最后一個(gè)被提交的事務(wù)）并且把存放該zxid的機(jī)器選舉為leader即可

還可以省去 Leader 服務(wù)器檢查事務(wù)的提交和丟棄工作的這一步操作。

2. 當(dāng)leader收到事務(wù)請(qǐng)求，并且還沒有發(fā)起事務(wù)投票之前，leader宕機(jī)。
   也就是只有l(wèi)eader服務(wù)器中有該事務(wù)，但是事務(wù)隨著leader的宕機(jī)被丟棄掉了

   
   
   事務(wù)投票之前

針對(duì)這種情況ZAP定義了：已經(jīng)被丟棄的消息不能再次出現(xiàn)

之前宕機(jī)的leader節(jié)點(diǎn)重新啟動(dòng)之后若再次被選為L(zhǎng)eader，要把之前沒有commit的事務(wù)重新commit，而當(dāng)前的epoch大于該事務(wù)的epoch所以事務(wù)會(huì)被丟棄而不會(huì)被重新加載。也就是只有當(dāng)事務(wù)zxid的epoch和當(dāng)前的epoch相同時(shí)，事務(wù)才會(huì)被提交

參考鏈接！https://www.cnblogs.com/stateis0/p/9062133.html