1、zookeeper工作原理
Zookeeper的核心是原子廣播,這個機制保證了各個server之間的同步。實現這個機制的協議叫做Zab協議。Zab協議有兩種模式,它們分別是恢復模式和廣播模式。當服務啓動或者在領導者崩潰後,Zab就進入了恢復模式,當領導者被選舉出來,且大多數server的完成了和leader的狀態同步以後,恢復模式就結束了。狀態同步保證了leader和server具有相同的系統狀態。一旦leader已經和多數的follower進行了狀態同步後,他就可以開始廣播消息了,即進入廣播狀態。這時候當一個server加入zookeeper服務中,它會在恢復模式下啓動,發現leader,並和leader進行狀態同步。待到同步結束,它也參與消息廣播。Zookeeper服務一直維持在Broadcast狀態,直到leader崩潰了或者leader失去了大部分的followers支持。廣播模式需要保證proposal被按順序處理,因此zk採用了遞增的事務id號(zxid)來保證。所有的提議(proposal)都在被提出的時候加上了zxid。實現中zxid是一個64爲的數字,它高32位是epoch用來標識leader關係是否改變,每次一個leader被選出來,它都會有一個新的epoch。低32位是個遞增計數。當leader崩潰或者leader失去大多數的follower,這時候zk進入恢復模式,恢復模式需要重新選舉出一個新的leader,讓所有的server都恢復到一個正確的狀態。
» 每個Server啓動以後都詢問其它的Server它要投票給誰。
» 對於其他server的詢問,server每次根據自己的狀態都回復自己推薦的leader的id和上一次處理事務的zxid(系統啓動時每個server都會推薦自己)
» 收到所有Server回覆以後,就計算出zxid最大的哪個Server,並將這個Server相關信息設置成下一次要投票的Server。
» 計算這過程中獲得票數最多的的sever爲獲勝者,如果獲勝者的票數超過半數,則改server被選爲leader。否則,繼續這個過程,直到leader被選舉出來
» leader就會開始等待server連接
» Follower連接leader,將最大的zxid發送給leader
» Leader根據follower的zxid確定同步點
» 完成同步後通知follower 已經成爲uptodate狀態
» Follower收到uptodate消息後,又可以重新接受client的請求進行服務了
2、zookeeper角色
3、zookeeper節點數據操作流程
步驟:
- 1.在Client向Follwer發出一個寫的請求
- 2.Follwer把請求發送給Leader
- 3.Leader接收到以後開始發起投票並通知Follwer進行投票
- 4.Follwer把投票結果發送給Leader
- 5.Leader將結果彙總後如果需要寫入,則開始寫入同時把寫入操作通知給Leader,然後commit;
- 6.Follwer把請求結果返回給Client
4、zookeeper的讀寫機制
- Zookeeper是一個由多個server組成的集羣
- 一個leader,多個follower
- 每個server保存一份數據副本
- 全局數據一致
- 分佈式讀寫
- 更新請求轉發,由leader實施
5、zookeeper的保證
- 更新請求順序進行,來自同一個client的更新請求按其發送順序依次執行
- 數據更新原子性,一次數據更新要麼成功,要麼失敗
- 全局唯一數據視圖,client無論連接到哪個server,數據視圖都是一致的
- 實時性,在一定事件範圍內,client能讀到最新數據