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内部狀态碼的對應關系如下：
| KeeperException.Code | Event.KeeperState | conn state |
|---|---|---|
| AUTHFAILED | AuthFailed | / |
| NOAUTH | AuthFailed | / |
| CONNECTIONLOSS | Disconnected | SUSPENDED |
| OPERATIONTIMEOUT | Disconnected | SUSPENDED |
| SESSIONEXPIRED | Expired | LOST |
| OK | SyncConnected | RECONNECTED |
| SESSIONMOVED | SyncConnected | RECONNECTED |
| / | ConnectedReadOnly | READ_ONLY |
而LeaderLatch中注冊的listener是處理conn state的，處理的流程圖如下：
可以看到，出現LOST或者SUSPENDED時，LeaderLatch都做降備處理，而對應的ZooKeeper狀态确實Disconnected，這是一種很常見的狀态。當ZooKeeper用戶端和服務端暫時斷開連接配接時，ZooKeeper用戶端收到的狀态就是Disconnected。
這樣就意味着在網絡情況較差，或者ZooKeeper叢集中的執行個體發生故障時，一定會導緻LeaderLatch降備行為的發生。我們知道在大規模叢集下，網絡情況偶爾閃斷、叢集節點下電、程序故障等情況發生的機率還是很大的。決不能容忍這些情況下LeaderLatch降備進而導緻服務的主備切換，增加服務的不可用時間。
針對這種情況，我們做了如下優化：
即在發生SUSPENDED事件後，會在降備之前等待一個connection timeout的時間，如果在此時間内ZooKeeper用戶端嘗試重連叢集成功，則忽略這次斷連時間。否則按照之前的處理邏輯，降備處理。
通過增加這一個緩沖區域，我們有效的降低了LeaderLatch（以及依賴其提供HA的上層服務）的可用性，大大減少了服務發生主備切換的頻率，效果提升明顯。
聲明：本文為原創，版權歸本人所有，禁止用于任何商業目的，轉載請注明出處：http://blog.csdn.net/asongoficeandfire/article/details/70667203
如果你覺得我文章寫的不錯，可以掃描支付寶二維碼打賞我：）