Zookeeper的核心:ZAB原子訊息廣播協議
ZooKeeper為高可用的一致性協調框架,自然的ZooKeeper也有著一致性演算法的實現,ZooKeeper使用的是ZAB協議作為資料一致性的演算法,ZAB(ZooKeeper Atomic Broadcast )全稱為:原子訊息廣播協議;ZAB可以說是在Paxos演算法基礎上進行了擴充套件改造而來的,ZAB協議設計了支援崩潰恢復,ZooKeeper使用單一主程式Leader用於處理客戶端所有事務請求,採用ZAB協議將伺服器數狀態以事務形式廣播到所有Follower上;由於事務間可能存在著依賴關係,ZAB協議保證Leader廣播的變更序列被順序的處理,:一個狀態被處理那麼它所依賴的狀態也已經提前被處理;ZAB協議支援的崩潰恢復可以保證在Leader程式崩潰的時候可以重新選出Leader並且保證資料的完整性;
在ZooKeeper中所有的事務請求都由一個主伺服器也就是Leader來處理,其他伺服器為Follower,Leader將客戶端的事務請求轉換為事務Proposal,並且將Proposal分發給叢集中其他所有的Follower,然後Leader等待Follwer反饋,當有過半數(>=N/2+1)的Follower反饋資訊後,Leader將再次向叢集內Follower廣播Commit資訊,Commit為將之前的Proposal提交;
一、協議狀態
ZAB協議中存在著三種狀態,每個節點都屬於以下三種中的一種:
1. Looking(發現):系統剛啟動時或者Leader崩潰後正處於選舉狀態
2. Following(同步):Follower節點所處的狀態,Follower與Leader處於資料同步階段;
3. Leading(領導):Leader所處狀態,當前叢集中有一個Leader為主程式;
ZooKeeper啟動時所有節點初始狀態為Looking,這時叢集會嘗試選舉出一個Leader節點,選舉出的Leader節點切換為Leading狀態;當節點發現叢集中已經選舉出Leader則該節點會切換到Following狀態,然後和Leader節點保持同步;當Follower節點與Leader失去聯絡時Follower節點則會切換到Looking狀態,開始新一輪選舉;在ZooKeeper的整個生命週期中每個節點都會在Looking、Following、Leading狀態間不斷轉換;
選舉出Leader節點後ZAB進入原子廣播階段,這時Leader為和自己同步的每個節點Follower建立一個操作序列,一個時期一個Follower只能和一個Leader保持同步,Leader節點與Follower節點使用心跳檢測來感知對方的存在;當Leader節點在超時時間內收到來自Follower的心跳檢測那Follower節點會一直與該節點保持連線;若超時時間內Leader沒有接收到來自過半Follower節點的心跳檢測或TCP連線斷開,那Leader會結束當前週期的領導,切換到Looking狀態,所有Follower節點也會放棄該Leader節點切換到Looking狀態,然後開始新一輪選舉;
二、演算法階段
ZAB協議定義了選舉(election)、發現(discovery)、同步(sync)、廣播(Broadcast)四個階段;ZAB選舉(election)時當Follower存在ZXID(事務ID)時判斷所有Follower節點的事務日誌,只有lastZXID的節點才有資格成為Leader,這種情況下選舉出來的Leader總有最新的事務日誌,基於這個原因所以ZooKeeper實現的時候把發現(discovery)與同步(sync)合併為恢復(recovery)階段;
1. Election:在Looking狀態中選舉出Leader節點,Leader的lastZXID總是最新的;
2. Discovery:Follower節點向準Leader推送FOllOWERINFO,該資訊中包含了上一週期的epoch,接受準Leader的NEWLEADER指令,檢查newEpoch有效性,準Leader要確保Follower的epoch與ZXID小於或等於自身的;
3. sync:將Follower與Leader的資料進行同步,由Leader發起同步指令,最總保持叢集資料的一致性;
4. Broadcast:Leader廣播Proposal與Commit,Follower接受Proposal與Commit;
5. Recovery:在Election階段選舉出Leader後本階段主要工作就是進行資料的同步,使Leader具有highestZXID,叢集保持資料的一致性;
1、選舉(Election)
election階段必須確保選出的Leader具有highestZXID,否則在Recovery階段沒法保證資料的一致性,Recovery階段Leader要求Follower向自己同步資料沒有Follower要求Leader保持資料同步,所有選舉出來的Leader要具有最新的ZXID;
在選舉的過程中會對每個Follower節點的ZXID進行對比只有highestZXID的Follower才可能當選Leader;
選舉流程:
1. 每個Follower都向其他節點傳送選自身為Leader的Vote投票請求,等待回覆;
2. Follower接受到的Vote如果比自身的大(ZXID更新)時則投票,並更新自身的Vote,否則拒絕投票;
3. 每個Follower中維護著一個投票記錄表,當某個節點收到過半的投票時,結束投票並把該Follower選為Leader,投票結束;
ZAB協議中使用ZXID作為事務編號,ZXID為64位數字,低32位為一個遞增的計數器,每一個客戶端的一個事務請求時Leader產生新的事務後該計數器都會加1,高32位為Leader週期epoch編號,當新選舉出一個Leader節點時Leader會取出本地日誌中最大事務Proposal的ZXID解析出對應的epoch把該值加1作為新的epoch,將低32位從0開始生成新的ZXID;ZAB使用epoch來區分不同的Leader週期;
2、恢復(Recovery)
在election階段選舉出來的Leader已經具有最新的ZXID,所有本階段的主要工作是根據Leader的事務日誌對Follower節點資料進行更新;
Leader:Leader生成新的ZXID與epoch,接收Follower傳送過來的FOllOWERINFO(含有當前節點的LastZXID)然後往Follower傳送NEWLEADER;Leader根據Follower傳送過來的LastZXID根據資料更新策略向Follower傳送更新指令;
同步策略:
1. SNAP:如果Follower資料太老,Leader將傳送快照SNAP指令給Follower同步資料;
2. DIFF:Leader傳送從Follolwer.lastZXID到Leader.lastZXID議案的DIFF指令給Follower同步資料;
3. TRUNC:當Follower.lastZXID比Leader.lastZXID大時,Leader傳送從Leader.lastZXID到Follower.lastZXID的TRUNC指令讓Follower丟棄該段資料;
Follower:往Leader傳送FOLLOERINFO指令,Leader拒絕就轉到Election階段;接收Leader的NEWLEADER指令,如果該指令中epoch比當前Follower的epoch小那麼Follower轉到Election階段;Follower還有主要工作是接收SNAP/DIFF/TRUNC指令同步資料與ZXID,同步成功後回覆ACKNETLEADER,然後進入下一階段;Follower將所有事務都同步完成後Leader會把該節點新增到可用Follower列表中;
SNAP與DIFF用於保證叢集中Follower節點已經Committed的資料的一致性,TRUNC用於拋棄已經被處理但是沒有Committed的資料;
3、廣播(Broadcast)
客戶端提交事務請求時Leader節點為每一個請求生成一個事務Proposal,將其傳送給叢集中所有的Follower節點,收到過半Follower的反饋後開始對事務進行提交,ZAB協議使用了原子廣播協議;在ZAB協議中只需要得到過半的Follower節點反饋Ack就可以對事務進行提交,這也導致了Leader幾點崩潰後可能會出現資料不一致的情況,ZAB使用了崩潰恢復來處理數字不一致問題;訊息廣播使用了TCP協議進行通訊所有保證了接受和傳送事務的順序性。廣播訊息時Leader節點為每個事務Proposal分配一個全域性遞增的ZXID(事務ID),每個事務Proposal都按照ZXID順序來處理;
Leader節點為每一個Follower節點分配一個佇列按事務ZXID順序放入到佇列中,且根據佇列的規則FIFO來進行事務的傳送。Follower節點收到事務Proposal後會將該事務以事務日誌方式寫入到本地磁碟中,成功後反饋Ack訊息給Leader節點,Leader在接收到過半Follower節點的Ack反饋後就會進行事務的提交,以此同時向所有的Follower節點廣播Commit訊息,Follower節點收到Commit後開始對事務進行提交;
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/30316686/viewspace-2106956/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- zookeeper核心之ZAB協議就這麼簡單!協議
- Zookeeper的ZAB協議與Paxos協議區別協議
- Zookeeper ZAB協議原理淺析協議
- 看大牛如何分析Zookeeper ZAB 協議協議
- Zookeeper應用場景和ZAB協議協議
- Zookeeper一致性協議——ZAB協議
- 廣播訊息
- Raft協議和ZAB協議Raft協議
- 分散式協調元件Zookeeper之 選舉機制與ZAB協議分散式元件協議
- ZooKeeper一致性協議ZAB學習筆記協議筆記
- ZAB協議的那些事?協議
- SpringBoot 實戰 (十六) | 整合 WebSocket 基於 STOMP 協議實現廣播訊息Spring BootWeb協議
- ActiveMQ支援的訊息協議MQ協議
- 簡述 zookeeper 基於 Zab 協議實現選主及事務提交協議
- 系列TCP/IP協議-廣播與多播(010)TCP協議
- 深入 RPC 訊息協議RPC協議
- HTTP協議訊息頭HTTP協議
- BadTunnel:跨網段劫持廣播協議協議
- SpringCloud 2020.0.4 系列之 Stream 訊息廣播 與 訊息分組 的實現SpringGCCloud
- 面試官:ZAB協議是什麼?面試協議
- RocketMQ系列(五)廣播與延遲訊息MQ
- MQTT協議 -- 訊息報文格式MQQT協議
- 網路協議之:WebSocket的訊息格式協議Web
- Laravel 6.x 公共廣播訊息筆記Laravel筆記
- Laravel 使用 Easywechat 書寫自定義模板訊息丶廣播訊息頻道Laravel
- 面試題:談談什麼是Zab協議?面試題協議
- 《球球大作戰》原始碼解析(8):訊息廣播原始碼
- 解讀ZooKeeper的Atomic Broadcast協議ZABFYAST協議
- Laravel + 微信小程式 websocket 搭建廣播訊息系統Laravel微信小程式Web
- 組播協議詳解協議
- TYPE-C PD供電協議訊息格式協議
- 訊息佇列面試解析 - 傳輸協議佇列面試協議
- Solon rpc 之 SocketD 協議 - 訊息鑑權模式RPC協議模式
- 詳解FIX協議的原理、訊息格式及配置開發協議
- 基於Netty實現自定義訊息通訊協議(協議設計及解析應用實戰)Netty協議
- springboot使用RabbitMQ的fanout廣播模式消費者死活接收不到訊息Spring BootMQ模式
- 面試官:能聊聊Paxos演算法和ZAB協議嗎面試演算法協議
- WebSocket 的故事(二)—— Spring 中如何利用 STOMP 快速構建 WebSocket 廣播式訊息模式WebSpring模式