轉載自?https://blog.csdn.net/qqqq0199181/article/details/80865828

眾所周知，zookeeper是一個開源的分布式協調服務，很多分布式的應用都是基于zookeeper來實現分布式鎖，服務管理，服務發現，通知訂閱等功能。那么。zookeeper自身是如何在分布式環境下實現數據的一致性的呢。

結構
既然zookeeper是在分布式環境下提供服務的，那么它必須要解決的問題就是單點問題，因此zookeeper是一個主備的結構。zookeeper 存在leader,follower,observer三種角色,這三種角色在實際服務集群中都是服務節點。

leader:處理所有請求，為客戶的提供讀和寫服務
follower:只提供讀服務，有機會通過選舉成為leader
observer:只提供讀服務?
由以上三種角色的介紹可知，zookeeper中所有請求都是交給leader處理的，因此，如果leader掛了，zookeeper就無法再提供服務，這就是單點問題。所幸在leader掛了之后，follower能夠通過選舉成為新的leader。?
那么問題來了，follower是如何被選舉成為新的leader的？新的leader又是如何保證數據的一致性的？這些問題的答案都在于zookeeper所用的分布式一致性協議ZAB。
ZAB協議
ZAB協議是為zookeeper專門設計的一種支持奔潰恢復的原子廣播協議。雖然它不像Paxos算法那樣通用通用，但是它卻比Paxos算法易于理解。在我看來ZAB協議主要的作用在于三個方面1、選舉出leader;2、同步節點之間的狀態達到數據一致；3、數據的廣播。

幾個概念的定義
在了解ZAB協議具體過程之前不要先了解幾個概念。

事務
zookeeper作為一個分布式協調服務，需要leader節點去接受外部請求，轉化為內部操作（比如創建，修改，刪除節點），需要原子性執行的幾個操作就組成了事務，這里用T代表。zookeeper要求有序的處理事務，因此給每個事務一個編號，每進來一個事務編號加1，假設leader節點中進來n個事務，可以表示為T1,T2,T3…Tn。為了防止單點問題導致事務數據丟失，leader節點會把事務數據同步到follower節點中。

事務隊列
leader和follower都會保存一個事務隊列，用L表示，L=T1,T2,T3…Tn，leader的事務隊列是接受請求保存下來的，follower的事務隊列是leader同步過來的，因此leader的事務隊列是最新，最全的。

任期
在zookeeper的工作過程中，leader節點奔潰，重新選舉出新的leader是很正常的事情，所以zookeeper的運行歷史中會產生多個leader，就好比一個國家的歷史中會相繼出現多為領導人。為了區分各個leader，ZAB協議用一個整數來表示任期，我們假設用E表示任務。zookeeper剛運行時選舉出的第一個leader的任期為E=1；第一個leader奔潰后，下面選舉出來的leader，任期會加1，E=2;一次類推。加入任期概念的事務應該表示為T(E,n)

協議過程
選舉leader
每個follower廣播自己事務隊列中最大事務編號maxId
獲取集群中其他follower發出來的maxId，選取出最大的maxId所屬的follower，投票給改follower，選它為leader。
統計所有投票，獲取投票數超過一半的follower被推選為leader
同步數據
各個follower向leader發送自己保存的任期E
leader,比較所有的任期，選取最大的E，加1后作為當前的任期E=E+1
將任務E廣播給所有follower
follower將任期改為leader發過來的值，并且返回給leader事務隊列L
leader從隊列集合中選取任期最大的隊列，如果有多個隊列任期都是最大，則選取事務編號n最大的隊列Lmax。將Lmax最為leader隊列，并且廣播給各個follower。
follower接收隊列替換自己的事務隊列，并且執行提交隊列中的事務。?
至此各個節點的數據達成一致，zookeeper恢復正常服務。
廣播
leader節點接收到請求，將事務加入事務隊列，并且將事務廣播給各個follower。
follower接收事務并加入都事務隊列，然后給leader發送準備提交請求。
leader 接收到半數以上的準備提交請求后，提交事務同時向follower 發送提交事務請求
follower提交事務。
?

總結

以上是生活随笔為你收集整理的zookeeper是如何实现数据一致性的？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。