Curator在大數據集群可靠性中的應用以及改進

Curator簡介

大家都知道，ZooKeeper是當前大數據領域內常用的分散式協調組件。幾乎在所有的大數據、分散式處理組件中都能見到它的應用。但由於ZooKeeper提供的原始API並不是很易用，在其基礎上封裝一些高級應用（服務發現、分散式鎖、Master選舉等）需要處理到很多細節，是一件很複雜的事情。

Curator在此場景下應運而生，由Netflix貢獻到Apache社區，至今已經成了各大廠商使用ZooKeeper服務的標配第三方庫。它提供了Framework模塊對ZooKeeper客戶端進行了高級封裝，並且對外包裝了連接狀態的處理以及重試邏輯，另外提供了Recipes模塊封裝一些針對ZooKeeper應用場景開發出來的高級特性（Elections、Locks、Barriers、Counters等等）。這次我們要介紹的就是Recipes模塊中的leader（Elections）子特性。

LeaderLatch與Master選舉

LeaderLatch是Curator中Elections特性中的主要介面，它封裝了一個CuratorFramework和一個用於選舉的ZooKeeper ZNode路徑。用於在多個實例中隨機選取一個作為Master實例，其他作為Standby實例備用；當Master實例發生故障或者退服後，再選舉其中一個Standby實例升主，繼續對外提供不間斷的服務。

LeaderLatch是怎麼參與Maser選舉的呢？流程是這樣的：在啟動時，在指定的latch path（由用戶指定）下建立一個前綴為latch-的ZNode，Create Mode選定為EPHEMERAL_SEQUENTIAL，EPHEMERAL指創建的節點為臨時節點，在session關閉後會被服務端刪除，SEQUENTIAL意味著在同一個path下創建的節點是遞增有序的。ZNode建立完畢後，會調用一個回調函數，在這個回調函數里處理Master競選的邏輯。

其實競選邏輯也很簡單，每個實例都會在指定的latch path下創建一個latch-前綴的ZNode，而在服務端這些請求是被順序處理的，且每個ZNode後綴是遞增有序的。那麼實例創建ZNode完成後，只需要將latch path下的所有ZNode取到，做一個排序，若本實例創建的ZNode在有序序列的第一個，則為leader；否則為standby實例，繼續監控排在本實例ZNode之前的實例節點（此處很妙，監控前一個ZNode而不是leader ZNode，是為了防止羊群效應）。當監控的節點被刪除時，重新觸發競選過程。

表示成圖如下：

LeaderLatch對ZooKeeper connection的敏感度及優化

以上說的是正常情況下的選舉邏輯，實際上LeaderLatch除了處理服務端ZNode節點的變化外，還要處理與ZooKeeper集群的連接狀態。當連接狀態發生變化時，LeaderLatch的競選邏輯也要做相應的改變。

我們先從LeaderLatch的組成部分開始：

LeaderLatch中有一個listener，會在啟動的時候加入到ConnStateManager的listner列表中，而CuratorFramework處理每次事件時，都會檢查Event的狀態，將ZooKeeper的狀態轉換為Curator內部狀態碼後，交由ConnStateManager處理，而ConnStateManager處理的最關鍵步驟就是作為匯流排將這些狀態傳遞註冊的listener。ZooKeeper連接狀態到Curator內部狀態碼的對應關係如下：

而LeaderLatch中註冊的listener是處理conn state的，處理的流程圖如下：

可以看到，出現LOST或者SUSPENDED時，LeaderLatch都做降備處理，而對應的ZooKeeper狀態確實Disconnected，這是一種很常見的狀態。當ZooKeeper客戶端和服務端暫時斷開連接時，ZooKeeper客戶端收到的狀態就是Disconnected。

這樣就意味著在網路情況較差，或者ZooKeeper集群中的實例發生故障時，一定會導致LeaderLatch降備行為的發生。我們知道在大規模集群下，網路情況偶爾閃斷、集群節點下電、進程故障等情況發生的概率還是很大的。決不能容忍這些情況下LeaderLatch降備從而導致服務的主備切換，增加服務的不可用時間。

針對這種情況，我們做了如下優化：

即在發生SUSPENDED事件後，會在降備之前等待一個connection timeout的時間，如果在此時間內ZooKeeper客戶端嘗試重連集群成功，則忽略這次斷連時間。否則按照之前的處理邏輯，降備處理。

通過增加這一個緩衝區域，我們有效的降低了LeaderLatch（以及依賴其提供HA的上層服務）的可用性，大大減少了服務發生主備切換的頻率，效果提升明顯。

聲明：本文為原創，首發於CSDN，版權歸本人所有，禁止用於任何商業目的，轉載請註明出處：Curator在大數據集群可靠性中的應用以及改進 - doggggggggggggggggggggggggggggggggggggie的專欄 - 博客頻道 - CSDN.NET

推薦閱讀：