111111 zookeeper功能及工做原理

Zookeeper server工做原理

Zookeeper的核心是原子廣播，這個機制保證了各個server之間的同步。實現這個機制的協議叫作Zab協議。Zab協議有兩種模式，它們分別是恢復模式和廣播模式。當服務啓動或者在領導者崩潰後，Zab就進入了恢復模式，當領導者被選舉出來，且大多數server的完成了和leader的狀態同步之後，恢復模式就結束了。狀態同步保證了leader和server具備相同的系統狀態。

 

ZAB 協議的核心：定義了事務請求的處理方式。

　　全部事務請求必須由一個全局惟一的服務器來協調處理，這樣的服務器被稱爲 Leader服務器，而餘下的其餘服務器則成爲 Follower 服務器。 Leader 服務器負責將一個客戶端事務請求轉換成一個事務proposal（提議），並將該 Proposal分發給集羣中全部的Follower服務器。以後 Leader 服務器須要等待全部Follower 服務器的反饋,一旦超過半數的Follower服務器進行了正確的反饋後，那麼 Leader 就會再次向全部的 Follower服務器分發Commit消息，要求其將前一個proposal進行提交。

　　這種事務處理方式與2PC（兩階段提交協議）區別在於，兩階段提交協議的第二階段中，須要等到全部參與者的"YES"回覆纔會提交事務，只要有一個參與者反饋爲"NO"或者超時無反饋，都須要中斷和回滾事務。

 

zxid是處理事務的id，是一個64爲的數字，它高32位是epoch用來標識leader關係是否改變，每次一個leader被選出來，它都會有一個新的epoch。低32位是個遞增計數。

因此每一個zk節點都會記錄上次運行事物到zxid，它能夠用來記錄當前zk節點運行到哪一個事物了。

同時zxid也是leader選舉的時候用來選擇server的依據，每一個node廣播本身的id和zxid，你們會選zxid最大的那個作爲leader，由於zxid越大說明執行的事物越多，node最解決最後的結果。選舉成功後follower鏈接leader，上報本身的zxid，leader會根據zxid，從事務日誌中將本身的內容與follower的同步一致。

在恢復模式下，若是是剛從崩潰狀態恢復的或者剛啓動的server還會從磁盤快照中恢復數據和會話信息，zk會記錄事務日誌並按期進行快照，方便在恢復時進行狀態恢復。

 

https://www.cnblogs.com/jian-xiao/p/5821675.html

http://blog.csdn.net/xqb_756148978/article/details/52259381

 

https://www.cnblogs.com/wangn/p/3361821.html