Zab協議（把zk leader處理的寫請求同步到follower及observer上）
|
|-定義:Zab協議 的全稱是 Zookeeper Atomic Broadcast (Zookeeper原子廣播).Zookeeper 是通過 Zab 協議來保證分佈式事務的最終一致性.
| |
| |--Zab協議是爲分佈式協調服務Zookeeper專門設計的一種 支持崩潰恢復 的 原子廣播協議 ,是Zookeeper保證數據一致性的核心算法.
| | Zab借鑑了Paxos算法,但又不像Paxos那樣,是一種通用的分佈式一致性算法.
| | 它是特別爲Zookeeper設計的支持崩潰恢復的原子廣播協議.
| |
| |--在Zookeeper中主要依賴Zab協議來實現數據一致性,基於該協議,zk實現了一種主備模型(即Leader和Follower模型)的系統架構來保證集羣中各個副本之間數據的一致性.
| | 這裏的主備系統架構模型,就是指只有一臺客戶端(Leader)負責處理外部的寫事務請求,然後Leader客戶端將數據同步到其他Follower節點.
| |
| |--Zookeeper 客戶端會隨機的鏈接到 zookeeper 集羣中的一個節點,如果是讀請求,就直接從當前節點中讀取數據；
| | 如果是寫請求,那麼節點就會向 Leader 提交事務,Leader 接收到事務提交,會廣播該事務,只要超過半數節點寫入成功,該事務就會被提交.
|
|-Zab 協議的特性|--Zab 協議需要確保那些已經在 Leader 服務器上提交(Commit)的事務最終被所有的服務器提交.
| |
| |--Zab 協議需要確保丟棄那些只在 Leader 上被提出而沒有被提交的事務.
| _________________________________________________________________________________________
| | Client Client Client |
| | \ | / |
| | \ | / |
| | \ | / 事務複製過程： |
| | ZK_Leader(寫數據) 1.proposal dispatch |
| | | 2.Ack 應答 |
| | ___________________|___________________ 3.Commit 過半響應後發生Commit指令 |
| | / / \ \ |
| | / / \ \ |
| | Zk_follower Zk_follower Zk_follower Zk_follower |
| |_________________________________________________________________________________________|
|
|-Zab 協議實現的作用
| |
| |--使用一個單一的主進程(Leader)來接收並處理客戶端的事務請求(也就是寫請求),並採用了Zab的原子廣播協議,
| | 將服務器數據的狀態變更以事務proposal (事務提議)的形式廣播到所有的副本(Follower)進程上去.
| |
| |--保證一個全局的變更序列被順序引用.
| | Zookeeper是一個樹形結構,很多操作都要先檢查才能確定是否可以執行,
| | 比如P1的事務t1可能是創建節點"/a",t2可能是創建節點"/a/bb",只有先創建了父節點"/a",才能創建子節點"/a/b".
| | 爲了保證這一點,Zab要保證同一個Leader發起的事務要按順序被apply,
| | 同時還要保證只有先前Leader的事務被apply之後,新選舉出來的Leader才能再次發起事務.
| |
| |--當主進程(Leader)出現異常的時候,整個zk集羣依舊能正常工作.
|
|-Zab協議原理
| |
| |--Zab協議要求每個 Leader 都要經歷三個階段：發現,同步,廣播.
| |
| |--發現：要求zookeeper集羣必須選舉出一個 Leader 進程,同時 Leader 會維護一個 Follower 可用客戶端列表.
| | 將來客戶端可以和這些 Follower節點進行通信.
| |
| |--同步：Leader 要負責將本身的數據與 Follower 完成同步,做到多副本存儲.這樣也是體現了CAP中的高可用和分區容錯.
| | Follower將隊列中未處理完的請求消費完成後,寫入本地事務日誌中.
| |
| |--廣播：Leader 可以接受客戶端新的事務Proposal請求,將新的Proposal請求廣播給所有的 Follower.
|
|-Zab協議核心
| |
| |--Zab協議的核心：定義了事務請求的處理方式
| |
| |--所有的事務請求必須由一個全局唯一的服務器來協調處理,這樣的服務器被叫做 Leader服務器.其他剩餘的服務器則是 Follower服務器.
| |
| |--Leader服務器 負責將一個客戶端事務請求,轉換成一個 事務Proposal,並將該 Proposal 分發給集羣中所有的 Follower 服務器,
| | 也就是向所有 Follower 節點發送數據廣播請求(或數據複製)
| |
| |--分發之後Leader服務器需要等待所有Follower服務器的反饋(Ack請求),在Zab協議中,
| | 只要超過半數的Follower服務器進行了正確的反饋後(也就是收到半數以上的Follower的Ack請求),
| | 那麼 Leader 就會再次向所有的 Follower服務器發送 Commit 消息,要求其將上一個 事務proposal 進行提交.
|
|-Zab協議內容(兩種模式)
| |
| |--Zab 協議包括兩種基本的模式：崩潰恢復 和 消息廣播
| |
| |--協議過程
| | |
| | |---當整個集羣啓動過程中,或者當 Leader 服務器出現網絡中斷、崩潰退出或重啓等異常時,Zab協議就會 進入崩潰恢復模式,選舉產生新的Leader.
| | |
| | |---當選舉產生了新的 Leader,同時集羣中有過半的機器與該 Leader 服務器完成了狀態同步(即數據同步)之後,Zab協議就會退出崩潰恢復模式,進入消息廣播模式.
| | |
| | |---這時,如果有一臺遵守Zab協議的服務器加入集羣,因爲此時集羣中已經存在一個Leader服務器在廣播消息,那麼該新加入的服務器自動進入恢復模式：
| | | 找到Leader服務器,並且完成數據同步.同步完成後,作爲新的Follower一起參與到消息廣播流程中.
| |
| |---狀態切換時機
| | |
| | |---當Leader出現崩潰退出或者機器重啓,亦或是集羣中不存在超過半數的服務器與Leader保存正常通信,
| | | Zab就會再一次進入崩潰恢復,發起新一輪Leader選舉並實現數據同步.
| | | 同步完成後又會進入消息廣播模式,接收事務請求.
|
|-保證消息有序(全局事務ID)
| |
| |--在整個消息廣播中,Leader會將每一個事務請求轉換成對應的 proposal 來進行廣播,
| | 並且在廣播 事務Proposal 之前,Leader服務器會首先爲這個事務Proposal分配一個全局單遞增的唯一ID,稱之爲事務ID(即zxid),
| | 由於Zab協議需要保證每一個消息的嚴格的順序關係,因此必須將每一個proposal按照其zxid的先後順序進行排序和處理.
|
|-消息廣播
| |
| |--特點:(類二階段提交)
| | |
| | |---在zookeeper集羣中,數據副本的傳遞策略就是採用消息廣播模式.zookeeper中數據副本的同步方式與二段提交相似,但是卻又不同.
| | |
| | | 二段提交要求協調者必須等到所有的參與者全部反饋ACK確認消息後,再發送commit消息.
| | | 要求所有的參與者要麼全部成功,要麼全部失敗.二段提交會產生嚴重的阻塞問題.
| | |
| | |---Zab協議中 Leader 等待 Follower 的ACK反饋消息是指“只要半數以上的Follower成功反饋即可,不需要收到全部Follower反饋”
| |
| |--具體步驟
| | |---1.客戶端發起一個寫操作請求
| | |---2.Leader 服務器將客戶端的請求轉化爲事務 Proposal 提案,同時爲每個 Proposal 分配一個全局的ID,即zxid.
| | |---3.Leader 服務器爲每個 Follower 服務器分配一個單獨的隊列,然後將需要廣播的 Proposal 依次放到隊列中取,並且根據 FIFO 策略進行消息發送.
| | |---4.Follower 接收到 Proposal 後,會首先將其以事務日誌的方式寫入本地磁盤中,寫入成功後向 Leader 反饋一個 Ack 響應消息.
| | |---5.Leader 接收到超過半數以上 Follower 的 Ack 響應消息後,即認爲消息發送成功,可以發送 commit 消息.
| | |---6.Leader 向所有 Follower 廣播 commit 消息,同時自身也會完成事務提交.Follower 接收到 commit 消息後,會將上一條事務提交.
| | |
| | |---zookeeper 採用 Zab 協議的核心,就是隻要有一臺服務器提交了 Proposal,就要確保所有的服務器最終都能正確提交 Proposal.
| | | 這也是 CAP/BASE 實現最終一致性的一個體現.
| | |
| | |---Leader 服務器與每一個 Follower 服務器之間都維護了一個單獨的 FIFO 消息隊列進行收發消息,使用隊列消息可以做到異步解耦.
| | | Leader 和 Follower 之間只需要往隊列中發消息即可.如果使用同步的方式會引起阻塞,性能要下降很多.
|
|-崩潰恢復
| |
| |--一旦 Leader 服務器出現崩潰或者由於網絡原因導致 Leader 服務器失去了與過半 Follower 的聯繫,那麼就會進入崩潰恢復模式.
| |
| |--在 Zab 協議中,爲了保證程序的正確運行,整個恢復過程結束後需要選舉出一個新的 Leader 服務器.
| | 因此 Zab 協議需要一個高效且可靠的 Leader 選舉算法,從而確保能夠快速選舉出新的 Leader .
| |
| |--Leader 選舉算法不僅僅需要讓 Leader 自己知道自己已經被選舉爲 Leader ,同時還需要讓集羣中的所有其他機器也能夠快速感知到選舉產生的新 Leader 服務器.
| |
| |--崩潰恢復主要包括兩部分：Leader選舉 和 數據恢復
|
|-Zab 協議如何保證數據一致性
| |
| |--假設兩種異常情況：
| | 1、一個事務在 Leader 上提交了,並且過半的 Folower 都響應 Ack 了,但是 Leader 在 Commit 消息發出之前掛了.
| | 2、假設一個事務在 Leader 提出之後,Leader 掛了.
| |
| |--要確保如果發生上述兩種情況,數據還能保持一致性,那麼 Zab 協議選舉算法必須滿足以下要求：
| | |
| | |---確保已經被 Leader 提交的 Proposal 必須最終被所有的 Follower 服務器提交.
| | |---確保丟棄已經被 Leader 提出的但是沒有被提交的 Proposal.
| | |
| | | 根據上述要求
| | |----Zab協議需要保證選舉出來的Leader需要滿足以下條件：
| | | 1)新選舉出來的 Leader 不能包含未提交的 Proposal .
| | | 即新選舉的 Leader 必須都是已經提交了 Proposal 的 Follower 服務器節點.
| | | 2)新選舉的 Leader 節點中含有最大的 zxid .
| | | 這樣做的好處是可以避免 Leader 服務器檢查 Proposal 的提交和丟棄工作.