zookeeper中的ZAB協議理解
ZAB協議
- ZAB協議是專門為zookeeper實現分散式協調功能而設計。zookeeper主要是根據ZAB協議是實現分散式系統資料一致性。
- zookeeper根據ZAB協議建立了主備模型完成zookeeper叢集中資料的同步。這裡所說的主備系統架構模型是指,在zookeeper叢集中,只有一臺leader負責處理外部客戶端的事物請求(或寫操作),然後leader伺服器將客戶端的寫操作資料同步到所有的follower節點中。
- ZAB的協議核心是在整個zookeeper叢集中只有一個節點即Leader將客戶端的寫操作轉化為事物(或提議proposal)。Leader節點再資料寫完之後,將向所有的follower節點發送資料廣播請求(或資料複製),等待所有的follower節點反饋。在ZAB協議中,只要超過半數follower節點反饋OK,Leader節點就會向所有的follower伺服器傳送commit訊息。即將leader節點上的資料同步到follower節點之上。
- ZAB協議中主要有兩種模式,第一是訊息廣播模式;第二是崩潰恢復模式
訊息廣播模式
- 在zookeeper叢集中資料副本的傳遞策略就是採用訊息廣播模式。zookeeper中資料副本的同步方式與二階段提交相似但是卻又不同。二階段提交的要求協調者必須等到所有的參與者全部反饋ACK確認訊息後,再發送commit訊息。要求所有的參與者要麼全部成功要麼全部失敗。二階段提交會產生嚴重阻塞問題。
- ZAB協議中Leader等待follower的ACK反饋是指”只要半數以上的follower成功反饋即可,不需要收到全部follower反饋”
- 圖中展示了訊息廣播的具體流程圖
- zookeeper中訊息廣播的具體步驟如下
4.1. 客戶端發起一個寫操作請求
4.2. Leader伺服器將客戶端的request請求轉化為事物proposql提案,同時為每個proposal分配一個全域性唯一的ID,即ZXID。
4.3. leader伺服器與每個follower之間都有一個佇列,leader將訊息傳送到該佇列
4.4. follower機器從佇列中取出訊息處理完(寫入本地事物日誌中)畢後,向leader伺服器傳送ACK確認。
4.5. leader伺服器收到半數以上的follower的ACK後,即認為可以傳送commit
4.6. leader向所有的follower伺服器傳送commit訊息。 - zookeeper採用ZAB協議的核心就是隻要有一臺伺服器提交了proposal,就要確保所有的伺服器最終都能正確提交proposal。這也是CAP/BASE最終實現一致性的一個體現
- leader伺服器與每個follower之間都有一個單獨的佇列進行收發訊息,使用佇列訊息可以做到非同步解耦。leader和follower之間只要往佇列中傳送了訊息即可。如果使用同步方式容易引起阻塞。效能上要下降很多。
崩潰恢復
- zookeeper叢集中為保證任何所有程序能夠有序的順序執行,只能是leader伺服器接受寫請求,即使是follower伺服器接受到客戶端的請求,也會轉發到leader伺服器進行處理。
- 如果leader伺服器發生崩潰,則zab協議要求zookeeper叢集進行崩潰恢復和leader伺服器選舉。
- ZAB協議崩潰恢復要求滿足如下2個要求:
3.1. 確保已經被leader提交的proposal必須最終被所有的follower伺服器提交。
3.2. 確保丟棄已經被leader出的但是沒有被提交的proposal。 - 根據上述要求,新選舉出來的leader不能包含未提交的proposal,即新選舉的leader必須都是已經提交了的proposal的follower伺服器節點。同時,新選舉的leader節點中含有最高的ZXID。這樣做的好處就是可以避免了leader伺服器檢查proposal的提交和丟棄工作。
- leader伺服器發生崩潰時分為如下場景:
5.1. leader在提出proposal時未提交之前崩潰,則經過崩潰恢復之後,新選舉的leader一定不能是剛才的leader。因為這個leader存在未提交的proposal。
5.2 leader在傳送commit訊息之後,崩潰。即訊息已經發送到佇列中。經過崩潰恢復之後,參與選舉的follower伺服器(剛才崩潰的leader有可能已經恢復執行,也屬於follower節點範疇)中有的節點已經是消費了佇列中所有的commit訊息。即該follower節點將會被選舉為最新的leader。剩下動作就是資料同步過程。
資料同步
- 在zookeeper叢集中新的leader選舉成功之後,leader會將自身的提交的最大proposal的事物ZXID傳送給其他的follower節點。follower節點會根據leader的訊息進行回退或者是資料同步操作。最終目的要保證叢集中所有節點的資料副本保持一致。
- 資料同步完之後,zookeeper叢集如何保證新選舉的leader分配的ZXID是全域性唯一呢?這個就要從ZXID的設計談起。
2.1 ZXID是一個長度64位的數字,其中低32位是按照數字遞增,即每次客戶端發起一個proposal,低32位的數字簡單加1。高32位是leader週期的epoch編號,至於這個編號如何產生(我也沒有搞明白),每當選舉出一個新的leader時,新的leader就從本地事物日誌中取出ZXID,然後解析出高32位的epoch編號,進行加1,再將低32位的全部設定為0。這樣就保證了每次新選舉的leader後,保證了ZXID的唯一性而且是保證遞增的。
ZAB協議原理
- ZAB協議要求每個leader都要經歷三個階段,即發現,同步,廣播。
- 發現:即要求zookeeper叢集必須選擇出一個leader程序,同時leader會維護一個follower可用列表。將來客戶端可以這follower中的節點進行通訊。
- 同步:leader要負責將本身的資料與follower完成同步,做到多副本儲存。這樣也是體現了CAP中高可用和分割槽容錯。follower將佇列中未處理完的請求消費完成後,寫入本地事物日誌中。
- 廣播:leader可以接受客戶端新的proposal請求,將新的proposal請求廣播給所有的follower。
Zookeeper設計目標
- zookeeper作為當今最流行的分散式系統應用協調框架,採用zab協議的最大目標就是建立一個高可用可擴充套件的分散式資料主備系統。即在任何時刻只要leader發生宕機,都能保證分散式系統資料的可靠性和最終一致性。
- 深刻理解ZAB協議,才能更好的理解zookeeper對於分散式系統建設的重要性。以及為什麼採用zookeeper就能保證分散式系統中資料最終一致性,服務的高可用性。
相關推薦
zookeeper中的ZAB協議理解
ZAB協議 ZAB協議是專門為zookeeper實現分散式協調功能而設計。zookeeper主要是根據ZAB協議是實現分散式系統資料一致性。 zookeeper根據ZAB協議建立了主備模型完成zoo
從Paxos到ZooKeeper(三)ZooKeeper的ZAB協議
ZAB協議 (一)ZAB協議是ZooKeeper實現資料一致性的核心演算法 (二)ZAB協議實現了一種主備模式的系統架構保持叢集中各副本之間資料的一致性 ZooKeeper使用單一的主程序接收並處理客戶端所有事務請求,採用ZAB的原子廣播協議,將伺服器資料狀態變更以事務Proposa
zookeeper核心-zab協議-《每日五分鐘搞定大資料》
上篇文章《paxos與一致性》說到zab是在paxos的基礎上做了重要的改造,解決了一系列的問題,這一篇我們就來說下這個zab。 zab協議的全稱是ZooKeeper Atomic Broadcast即zookeeper“原子”“廣播”協議。它規定了兩種模式:崩潰恢復和訊息廣播 恢復模式 什麼時候進入?
zab協議理解
ZAB協議是專門為zookeeper實現分散式協調功能而設計。zookeeper主要是根據ZAB協議是實現分散式系統資料一致性。 zookeeper根據ZAB協議建立了主備模型完成zookeeper叢集中資料的同步。這裡所說的主備系統架構模型是指,在zookee
zookeeper的zab協議工作原理之 崩潰恢復模式
下篇 來詳細的講解 崩潰恢復模式 的原理一、什麼情況下zab協議會進入崩潰恢復模式? 1、當伺服器啟動時 2、當leader 伺服器出現網路中斷,崩潰或者重啟的情況 3、當叢集中已經不存在過半的伺服器與Leader伺服器保持正常通訊。二、zab協議進入崩潰恢復
Zookeeper——初識ZAB協議
對於使用過Zookeeper的開發人員來說,都應該對ZAB協議有所耳聞。它是為分散式協調服務Zookeeper專門設計的一種支援崩潰恢復的原子廣播協議,全稱是Zookeeper Atomic Broadcast(Zookeeper原子訊息廣播協議)。今天就介紹一下ZAB協議主
簡述 zookeeper 基於 Zab 協議實現選主及事務提交
Zab 協議:zookeeper 基於 Paxos 協議的改進協議 zookeeper atomic broadcast 原子廣播協議。 zookeeper 基於 Zab 協議實現選主及事務提交。 一、為什麼需要選主? 選主是複雜分散式服務的一個特有機制,旨在保障系統資料的一致性。 分散式
zookeeper中的一致性協議zab
關於一致性協議 說起分散式一致性協議的始祖,就不得不提到larmport大師發表的< The Part-Time Parliament>論文,但在這個論文中描述的paxos演算法很長時間只停留在理論階段,在實際的工程中又出現了很多的變種。Zooke
zookeeper中的ZAB協議
ZAB協議用途 ZAB(Zookeeper Atomic Broadcast) 協議是為分散式協調服務zookeeper專門設計的一種支援崩潰恢復的原子廣播協議。在zookeeper中,主要依賴ZAB協議來實現分散式資料一致性,基於該協議,zookeeper實
Zookeeper ZAB 協議分析
指令 get 不同 保持 lead 細節 決定 rsquo res 前言 ZAB 協議是為分布式協調服務 ZooKeeper 專門設計的一種支持崩潰恢復的原子廣播協議。在 ZooKeeper 中,主要依賴 ZAB 協議來實現分布式數據一致性,基於該協議,ZooKeeper
Zookeeper的一致性協議:Zab
支持 源碼 proc 源碼實現 multipl 客戶端連接 red 使用 補充 Zookeeper使用了一種稱為Zab(Zookeeper Atomic Broadcast)的協議作為其一致性復制的核心,據其作者說這是一種新發算法,其特點是充分考慮了Yahoo的具體情況:高
理解ZAB協議
bsp size pos 加入集群 body 副本 寫入 zookeeper 最大 ZAB協議 介紹 1、zab協議是為分布式協調服務zookpeer專門設計的一種支持崩潰恢復的原子廣播協議 2、在zookeeper中主要依賴ZAB協議來實現數據一致性,基於該協
zookeeper 入門系列-理論基礎 – zab 協議
prefix 什麽 cast 復雜度 通信 隊列 xid zab協議 合並 上一章討論了paxos算法,把paxos推到一個很高的位置。但是,paxos有沒有什麽問題呢?實際上,paxos還是有其自身的缺點的: 1. 活鎖問題。在base-paxos算法中,不存在leade
Zookeeper-ZAB協議
1.ZAB協議的核心 在一個zk叢集中,只有一個leader節點可以將客戶端的寫請求轉化為事務或提議proposal,leader節點寫完資料庫, 把proposal訊息傳送到leader和follower直接的通訊佇列中去
zookeeper-非常重要的zab協議-《每日五分鐘搞定大資料》
上篇文章paxos與一致性說到zab是在paxos的基礎上做了重要的改造,解決了一系列的問題,這一篇我們就來說下這個zab。 zab協議的全稱是ZooKeeper Atomic Broadcast即zookeeper“原子”“廣播”協議。它規定了兩種模式:崩潰恢復和訊息廣播 恢復模式 什麼時候進入? 當整
Zookeeper ZAB協議
Zookeeper Automic Broadcast(ZAB),是paxos經典實現。 ZAB(zookeeper)中節點分四個狀態: 1.looking:選舉leader的狀態(崩潰下恢復)
分散式事物中二段提交協議、三段提交協議理解
1、二段提交協議 2pc,以下圖為理解基礎: 提交事務階段------投票階段 協調者發起事務請求到所有的參與者,參與者接收到事務請求後判斷自身情況,如果不能執行事務,則反饋不能提交事務,返回NO,如果可以就執行事務,並將undo和redo資訊記錄事務日誌中,反饋Yes
zookeeper入門系列-理論基礎-zab協議
上一章討論了paxos演算法,把paxos推到一個很高的位置。但是,paxos有沒有什麼問題呢?實際上,paxos還是有其自身的缺點的: 1. 活鎖問題。在base-paxos演算法中,不存在leader這樣的角色,於是存在這樣一種情況,即P1提交了一個proposal n
對於Zookeeper中提及的排它鎖、共享鎖和悲觀鎖、樂觀鎖的理解
排它鎖 (簡稱X鎖),又稱為寫鎖或獨佔鎖,是一種基本的鎖型別。如果事務T1對資料物件O1加上了排它鎖,那麼在整個加鎖期間,只允許事務T1對O1進行讀取和更新操作,其它任何事務都幫你再對這個資料物件進行任何型別的操作,——直到T1釋放了排它鎖。 從上邊講解的排
[zookeeper] zab協議
一、描述 zab(ZooKeeper Atomic Broadcast原子訊息廣播協議),是zookeeper一致性協議,zab協議主要包括兩種模式,訊息廣播和奔潰恢復 二、角色 zookeeper中主要的兩種角色,leader和follower,這兩種角色都有投票權