Zookeeper流程

漏船載酒發表於2017-10-28

原理概括

Zookeeper的核心是原子廣播,這個機制保證了各個Server之間的同步。實現這個機制的協議叫做Zab協議。Zab協議有兩種模式,它們分別是恢復模式(選主)和廣播模式(同步)。當服務啟動或者在領導者崩潰後,Zab就進入了恢復模式,當領導者被選舉出來,且大多數Server完成了和leader的狀態同步以後,恢復模式就結束了。狀態同步保證了leader和Server具有相同的系統狀態。
為了保證事務的順序一致性,zookeeper採用了遞增的事務id號(zxid)來標識事務。所有的提議(proposal)都在被提出的時候加上了zxid。實現中zxid是一個64位的數字,它高32位是epoch用來標識leader關係是否改變,每次一個leader被選出來,它都會有一個新的epoch,標識當前屬於那個leader的統治時期。低32位用於遞增計數。
每個Server在工作過程中有三種狀態:
LOOKING:當前Server不知道leader是誰,正在搜尋
LEADING:當前Server即為選舉出來的leader
FOLLOWING:leader已經選舉出來,當前Server與之同步

選主流程

當leader崩潰或者leader失去大多數的follower,這時候zk進入恢復模式,恢復模式需要重新選舉出一個新的leader,讓所有的Server都恢復到一個正確的狀態。Zk的選舉演算法有兩種:一種是基於basic paxos實現的,另外一種是基於fast paxos演算法實現的。系統預設的選舉演算法為fast paxos。先介紹basic paxos流程:
1.選舉執行緒由當前Server發起選舉的執行緒擔任,其主要功能是對投票結果進行統計,並選出推薦的Server;
2.選舉執行緒首先向所有Server發起一次詢問(包括自己);
3.選舉執行緒收到回覆後,驗證是否是自己發起的詢問(驗證zxid是否一致),然後獲取對方的id(myid),並儲存到當前詢問物件列表中,最後獲取對方提議的leader相關資訊(id,zxid),並將這些資訊儲存到當次選舉的投票記錄表中;
4. 收到所有Server回覆以後,就計算出zxid最大的那個Server,並將這個Server相關資訊設定成下一次要投票的Server;
5. 執行緒將當前zxid最大的Server設定為當前Server要推薦的Leader,如果此時獲勝的Server獲得n/2 + 1的Server票數, 設定當前推薦的leader為獲勝的Server,將根據獲勝的Server相關資訊設定自己的狀態,否則,繼續這個過程,直到leader被選舉出來。
通過流程分析我們可以得出:要使Leader獲得多數Server的支援,則Server總數必須是奇數2n+1,且存活的Server的數目不得少於n+1.
每個Server啟動後都會重複以上流程。在恢復模式下,如果是剛從崩潰狀態恢復的或者剛啟動的server還會從磁碟快照中恢復資料和會話資訊,zk會記錄事務日誌並定期進行快照,方便在恢復時進行狀態恢復

同步流程

選完leader以後,zk就進入狀態同步過程。

  1. leader等待server連線;
  2. .Follower連線leader,將最大的zxid傳送給leader;

3 .Leader根據follower的zxid確定同步點;
4 .完成同步後通知follower 已經成為uptodate狀態;
5 .Follower收到uptodate訊息後,又可以重新接受client的請求進行服務了。

follower工作流程

Follower主要有四個功能:

  1. 向Leader傳送請求(PING訊息、REQUEST訊息、ACK訊息、REVALIDATE訊息);
  2. .接收Leader訊息並進行處理;

3 .接收Client的請求,如果為寫請求,傳送給Leader進行投票;
4 .返回Client結果。
Follower的訊息迴圈處理如下幾種來自Leader的訊息:
1 .PING訊息: 心跳訊息;
2 .PROPOSAL訊息:Leader發起的提案,要求Follower投票;
3 .COMMIT訊息:伺服器端最新一次提案的資訊;
4 .UPTODATE訊息:表明同步完成;
5 .REVALIDATE訊息:根據Leader的REVALIDATE結果,關閉待revalidate的session還是允許其接受訊息;
6 .SYNC訊息:返回SYNC結果到客戶端,這個訊息最初由客戶端發起,用來強制得到最新的更新。


相關文章