ZooKeeper集羣與Leader選舉

ZooKeeper是一個開源分佈式協調服務、分佈式數據一致性解決方案。可基於ZooKeeper實現命名服務、集羣管理、Master選舉、分佈式鎖等功能。

一、高可用

爲了保證ZooKeeper的可用性,在生產環境中我們使用ZooKeeper集羣模式對外提供服務,並且集羣規模至少由3個ZooKeeper節點組成。

1.集羣至少由3個節點組成

ZooKeeper其實2個節點也可以組成集羣並對外提供服務,但我們使用集羣主要目的是爲了高可用。如果2個節點組成集羣,其中1個節點掛了,另外ZooKeeper節點不能正常對外提供服務。因此也失去了集羣的意義。

如果3個節點組成集羣,其中1個節點掛掉後,根據ZooKeeper的Leader選舉機制是可以從另外2個節點選出一個作爲Leader的,集羣可以繼續對外提供服務。

2.並非節點越多越好

  • 節點越多,使用的資源越多
  • 節點越多,ZooKeeper節點間花費的通訊成本越高,節點間互連的Socket也越多。影響ZooKeeper集羣事務處理
  • 節點越多,造成腦裂的可能性越大

3.集羣規模爲奇數

集羣規模除了考慮自身成本和資源外還要結合ZooKeeper特性考慮:

  • 節省資源

3節點集羣和4節點集羣,我們選擇使用3節點集羣;5節點集羣和6節點集羣,我們選擇使用5節點集羣。以此類推。因爲生產環境爲了保證高可用,3節點集羣最多隻允許掛1臺,4節點集羣最多也只允許掛1臺(過半原則中解釋了原因)。同理5節點集羣最多允許掛2臺,6節點集羣最多也只允許掛2臺。
出於對資源節省的考慮,我們應該使用奇數節點來滿足相同的高可用性。

  • 集羣可用性

當集羣中節點間網絡通訊出現問題時奇數和偶數對集羣的影響

clipboard.png

4.集羣配置

ZooKeeper集羣配置至少需要2處變更:

01 增加集羣配置

在{ZK_HOME}/conf/zoo.cfg中增加集羣的配置,結構以server.id=ip:port1:port2爲標準。

比如下面配置文件中表示由3個ZooKeeper組成的集羣:

server.1=localhost:2881:3881
server.2=localhost:2882:3882
server.3=localhost:2883:3883

clipboard.png

02 配置節點id

zoo.cfg中配置集羣時需要指定server.id,這個id需要在dataDir(zoo.cfg中配置)指定的目錄中創建myid文件,文件內容就是當前ZooKeeper節點的id。

二、集羣角色

ZooKeeper沒有使用Master/Slave的概念,而是將集羣中的節點分爲了3類角色:

  • Leader

在一個ZooKeeper集羣中,只能存在一個Leader,這個Leader是集羣中事務請求唯一的調度者和處理者,所謂事務請求是指會改變集羣狀態的請求;Leader根據事務ID可以保證事務處理的順序性。
如果一個集羣中存在多個Leader,這種現象稱爲「腦裂」。試想一下,一個集羣中存在多個Leader會產生什麼影響?
相當於原本一個大集羣,裂出多個小集羣,他們之間的數據是不會相互同步的。「腦裂」後集羣中的數據會變得非常混亂。

  • Follower

Follower角色的ZooKeeper服務只能處理非事務請求;如果接收到客戶端事務請求會將請求轉發給Leader服務器;參與Leader選舉;參與Leader事務處理投票處理。
Follower發現集羣中Leader不可用時會變更自身狀態,併發起Leader選舉投票,最終集羣中的某個Follower會被選爲Leader。

  • Observer

Observer與Follower很像,可以處理非事務請求;將事務請求轉發給Leader服務器。
與Follower不同的是,Observer不會參與Leader選舉;不會參與Leader事務處理投票。
Observer用於不影響集羣事務處理能力的前提下提升集羣的非事務處理能力。

三、Leader選舉

Leader在集羣中是非常重要的一個角色,負責了整個事務的處理和調度,保證分佈式數據一致性的關鍵所在。既然Leader在ZooKeeper集羣中這麼重要所以一定要保證集羣在任何時候都有且僅有一個Leader存在。

如果集羣中Leader不可用了,需要有一個機制來保證能從集羣中找出一個最優的服務晉升爲Leader繼續處理事務和調度等一系列職責。這個過程稱爲Leader選舉。

1.選舉機制

ZooKeeper選舉Leader依賴下列原則並遵循優先順序:

01 選舉投票必須在同一輪次中進行

如果Follower服務選舉輪次不同,不會採納投票。

02 數據最新的節點優先成爲Leader

數據的新舊使用事務ID判定,事務ID越大認爲節點數據約接近Leader的數據,自然應該成爲Leader。

03 比較server.id,id值大的優先成爲Leader

如果每個參與競選節點事務ID一樣,再使用server.id做比較。server.id是節點在集羣中唯一的id,myid文件中配置。

不管是在集羣啓動時選舉Leader還是集羣運行中重新選舉Leader。集羣中每個Follower角色服務都是以上面的條件作爲基礎推選出合適的Leader,一旦出現某個節點被過半推選,那麼該節點晉升爲Leader。

2.過半原則

ZooKeeper集羣會有很多類型投票。Leader選舉投票;事務提議投票;這些投票依賴過半原則。就是說ZooKeeper認爲投票結果超過了集羣總數的一半,便可以安全的處理後續事務。

  • 事務提議投票

假設有3個節點組成ZooKeeper集羣,客戶端請求添加一個節點。Leader接到該事務請求後給所有Follower發起「創建節點」的提議投票。如果Leader收到了超過集羣一半數量的反饋,繼續給所有Follower發起commit。此時Leader認爲集羣過半了,就算自己掛了集羣也是安全可靠的。

  • Leader選舉投票

假設有3個節點組成ZooKeeper集羣,這時Leader掛了,需要投票選舉Leader。當相同投票結果過半後Leader選出。

  • 集羣可用節點

ZooKeeper集羣中每個節點有自己的角色,對於集羣可用性來說必須滿足過半原則。這個過半是指Leader角色 + Follower角色可用數大於集羣中Leader角色 + Follower角色總數。
假設有5個節點組成ZooKeeper集羣,一個Leader、兩個Follower、兩個Observer。當掛掉兩個Follower或掛掉一個Leader和一個Follower時集羣將不可用。因爲Observer角色不參與任何形式的投票。
所謂過半原則算法是說票數 > 集羣總節點數/2。其中集羣總節點數/2的計算結果會向下取整。
在ZooKeeper源代碼QuorumMaj.java中實現了這個算法。下面代碼片段有所縮減。

public boolean containsQuorum(HashSet<Long> set) {
  /** n是指集羣總數 */
  int half = n / 2;
  return (set.size() > half);
}

回過頭我們看一下奇數和偶數集羣在Leader選舉的結果

clipboard.png

所以3節點和4節點組成的集羣在ZooKeeper過半原則下都最多隻能掛1節點,但是4比3要多浪費一個節點資源。

四、場景實戰

我們以兩個場景來了解集羣不可用時Leader重新選舉的過程。

1.3節點集羣重選Leader

假設有3節點組成的集羣,分別是server.1(Follower)、server.2(Leader)、server.3(Follower)。此時server.2不可用了。集羣會產生以下變化:

集羣不可用

因爲Leader掛了,集羣不可用於事務請求了。

02 狀態變更

所有Follower節點變更自身狀態爲LOOKING,並且變更自身投票。投票內容就是自己節點的事務ID和server.id。我們以(事務ID, server.id)表示。

假設server.1的事務id是10,變更的自身投票就是(10, 1);server.3的事務id是8,變更的自身投票就是(8, 3)。

03 首輪投票

將變更的投票發給集羣中所有的Follower節點。server.1將(10, 1)發給集羣中所有Follower,包括它自己。server.3也一樣,將(8, 3)發給所有Follower。

所以server.1將收到(10, 1)和(8, 3)兩個投票,server.3將收到(8, 3)和(10, 1)兩個投票。

04 投票PK

每個Follower節點除了發起投票外,還接其他Follower發來的投票,並與自己的投票PK(比較兩個提議的事務ID以及server.id),PK結果決定是否要變更自身狀態並再次投票。

對於server.1來說收到(10, 1)和(8, 3)兩個投票,與自己變更的投票比較後沒有一個比自身投票(10, 1)要大的,所以server.1維持自身投票不變。

對於server.3來說收到(10, 1)和(8, 3)兩個投票,與自身變更的投票比較後認爲server.1發來的投票要比自身的投票大,所以server.3會變更自身投票並將變更後的投票發給集羣中所有Follower。

05 第二輪投票

server.3將自身投票變更爲(10, 1)後再次將投票發給集羣中所有Follower。

對於server.1來說在第二輪收到了(10, 1)投票,server.1經過PK後繼續維持不變。

對於server.3來說在第二輪收到了(10, 1)投票,因爲server.3自身已變更爲(10, 3)投票,所以本次也維持不變。

此時server.1和server.3在投票上達成一致。

06 投票接收桶

節點接收的投票存儲在一個接收桶裏,每個Follower的投票結果在桶內只記錄一次。ZooKeeper源碼中接收桶用Map實現。

下面代碼片段是ZooKeeper定義的接收桶,以及向桶內寫入數據。Map.Key是Long類型,用來存儲投票來源節點的server.id,Vote則是對應節點的投票信息。節點收到投票後會更新這個接收桶,也就是說桶裏存儲了所有Follower節點的投票並且僅存最後一次的投票結果。

HashMap<Long, Vote> recvset = new HashMap<Long, Vote>();
recvset.put(n.sid, new Vote(n.leader, n.zxid, n.electionEpoch, n.peerEpoch));

07 統計投票

接收到投票後每次都會嘗試統計投票,投票統計過半後選舉成功。

投票統計的數據來源於投票接收桶裏的投票數據,我們從頭描述這個場景,來看一下接收桶裏的數據變化情況。

server.2掛了後,server.1和server.3發起第一輪投票。

server.1接收到來自server.1的(10, 1)投票和來自server.3的(8, 3)投票。

server.3同樣接收到來自server.1的(10, 1)投票和來自server.3的(8, 3)投票。此時server.1和server.3接收桶裏的數據是這樣的:

clipboard.png

server.3經過PK後認爲server.1的選票比自己要大,所以變更了自己的投票並重新發起投票。

server.1收到了來自server.3的(10, 1)投票;server.3收到了來自sever.3的(10, 1)投票。此時server.1和server.3接收桶裏的數據變成了這樣:

clipboard.png

基於ZooKeeper過半原則:桶內投票選舉server.1作爲Leader出現2次,滿足了過半 2 > 3/2 即 2>1。

最後sever.1節點晉升爲Leader,server.3變更爲Follower。

2.集羣擴容Leader啓動時機

ZooKeeper集羣擴容需要在zoo.cfg配置文件中加入新節點。擴容流程在ZooKeeper擴容中介紹。這裏我們以3節點擴容到5節點時,Leader啓動時機做一個討論。

假設目前有3個節點組成集羣,分別是server.1(Follower)、server.2(Leader)、server.3(Follower),假設集羣中節點事務ID相同。配置文件如下。

server.1=localhost:2881:3881
server.2=localhost:2882:3882
server.3=localhost:2883:3883

01 新節點加入集羣

集羣中新增server.4和server.5兩個節點,首先修改server.4和server.5的zoo.cfg配置並啓動。節點4和5在啓動後會變更自身投票狀態,發起一輪Leader選舉投票。server.1、server.2、server.3收到投票後由於集羣中已有選定Leader,所以會直接反饋server.4和server.5投票結果:server.2是Leader。server.4和server.5收到投票後基於過半原則認定server.2是Leader,自身便切換爲Follower。

節點server.1、server.2、server.3配置
server.1=localhost:2881:3881
server.2=localhost:2882:3882
server.3=localhost:2883:3883

#節點server.4、server.5配置
server.1=localhost:2881:3881
server.2=localhost:2882:3882
server.3=localhost:2883:3883
server.4=localhost:2884:3884
server.5=localhost:2885:3885

02 停止Leader

server.4和server.5的加入需要修改集羣server.1、server.2、server.3的zoo.cfg配置並重啓。但是Leader節點何時重啓是有講究的,因爲Leader重啓會導致集羣中Follower發起Leader重新選舉。在server.4和server.5兩個新節點正常加入後,集羣不會因爲新節點加入變更Leader,所以目前server.2依然是Leader。

我們以一個錯誤的順序啓動,看一下集羣會發生什麼樣的變化。修改server.2zoo.cfg配置文件,增加server.4和server.5的配置並停止server.2服務。停止server.2後,Leader不存在了,集羣中所有Follower會發起投票。當server.1和server.3發起投票時並不會將投票發給server.4和server.5,因爲在server.1和server.3的集羣配置中不包含server.4和server.5節點。相反,server.4和server.5會把選票發給集羣中所有節點。也就是說對於server.1和server.3他們認爲集羣中只有3個節點。對於server.4和server.5他們認爲集羣中有5個節點。

根據過半原則,server.1和server.3很快會選出一個新Leader,我們這裏假設server.3晉級成爲了新Leader。但是我們沒有啓動server.2的情況下,因爲投票不滿足過半原則,server.4和server.5會一直做投票選舉Leader的動作。截止到現在集羣中節點狀態是這樣的:

clipboard.png

03 啓動Leader

現在,我們啓動server.2。因爲server.2zoo.cfg已經是server.1到serverv.5的全量配置,在server.2啓動後會發起選舉投票,同時serverv.4和serverv.5也在不斷的發起選舉投票。當server.2的選舉輪次和serverv.4與serverv.5選舉輪次對齊後,最終server.2會變更自己的狀態,認定server.5是Leaader。

意想不到的事情發生了,出現兩個Leader:

clipboard.png

ZooKeeper集羣擴容時,如果Leader節點最後啓動就可以避免這類問題發生,因爲在Leader節點重啓前,所有的Follower節點zoo.cfg配置已經是相同的,他們基於同一個集羣配置兩兩互聯,做投票選舉。

作者:史天舒

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章