Storm nimbus HA

1、storm組件

Storm在集羣上運行一個Topology時，主要經過如下3個實體來完成Topology的執行工做：
1. Worker（進程）
2. Executor（線程）
3. Task
下圖簡要描述了這3者之間的關係：

1個worker進程執行的是1個topology的子集（注：不會出現1個worker爲多個topology服務）。1個worker進程會啓動1個或多個executor線程來執行1個topology的component(spout或bolt)。所以，1個運行中的topology就是由集羣中多臺物理機上的多個worker進程組成的。
executor是1個被worker進程啓動的單獨線程。每一個executor只會運行1個topology的1個component(spout或bolt)的task（注：task能夠是1個或多個，storm默認是1個component只生成1個task，executor線程裏會在每次循環裏順序調用全部task實例）。
task是最終運行spout或bolt中代碼的單元（注：1個task即爲spout或bolt的1個實例，executor線程在執行期間會調用該task的nextTuple或execute方法）。topology啓動後，1個component(spout或bolt)的task數目是固定不變的，但該component使用的executor線程數能夠動態調整（例如：1個executor線程能夠執行該component的1個或多個task實例）。這意味着，對於1個component存在這樣的條件：#threads<=#tasks（即：線程數小於等於task數目）。默認狀況下task的數目等於executor線程數目，即1個executor線程只運行1個task。

2、Storm nimbus單點問題

一、storm集羣在生產環境部署以後，一般會是以下的結構：

從圖中能夠看出zookeeper和supervisor都是多節點，任意1個zookeeper節點宕機或supervisor節點宕機均不會對系統總體運行形成影響，但nimbus和ui都是單節點。ui的單節點對系統的穩定運行沒有影響，僅提供storm-ui頁面展現統計信息。但nimbus承載了集羣的許多工做，若是nimbus單節點宕機，將會使系統總體的穩定運行形成極大風險。所以解決nimbus的單點問題，將會更加完善storm集羣的穩定性。

二、storm nimbus單節點的風險
(1)功能上，nimbus進程退出後，若是再同時發生worker進程宕機，宕機的worker將沒法重啓，集羣將會有部分消息始終沒法獲得處理。
(2)監控上，nimbus進程不可用時，storm ui將沒法訪問。
(3)概率上，機房因爲演練或故障不可用時即會出現nimbus與worker進程同時故障的情形，面對風險的概率較大。

三、storm與解決nimbus單點相關的概念

【nimbus進程】storm集羣工做的全局指揮官。
(1)經過thrift接口，監聽並接收client對topology的submit，將topology代碼保存到本地目錄/nimbus/stormdist/下
(2)爲client提交的topology計算任務分配，根據集羣worker資源狀況，計算出topology的spout和bolt的task應該如何在worker間分配，任務分配結果寫入zookeeper
(3)經過thrift接口，監聽supervisor的下載topology代碼的請求，並提供下載
(4)經過thrift接口，監聽ui對統計信息的讀取，從zookeeper上讀取統計信息，返回給ui
(5)若進程退出後，當即在本機重啓，則不影響集羣運行。

【supervisor進程】storm集羣的資源管理者，按需啓動worker進程。
(1)定時從zookeeper檢查是否有代碼未下載到本地的新topology，定時刪除舊topology代碼
(2)根據nimbus的任務分配結果，在本機按需啓動1個或多個worker進程，監控守護全部的worker進程。
(3)若進程退出，當即在本機重啓，則不影響集羣運行。

【worker進程】storm集羣的任務構造者，構造spout或bolt的task實例，啓動executor線程。
(1)根據zookeeper上分配的task，在本進程中啓動1個或多個executor線程，將構造好的task實例交給executor去運行（死循環調用spout.nextTuple()或bolt.execute()方法）。
(2)向zookeeper寫入心跳
(3)維持傳輸隊列，發送tuple到其餘的worker
(4)若進程退出，當即在本機重啓，則不影響集羣運行。

【executor線程】storm集羣的任務執行者，循環執行task代碼。
(1)執行1個或多個task（每一個task對應spout或bolt的1個並行度），將輸出加入到worker裏的tuple隊列
(2)執行storm內部線程acker，負責發送消息處理狀態給對應spoult所在的worker

nimbus目前沒法作到多節點的緣由

一、nimbus節點的ip地址在配置文件中storm.yaml，更換機器後ip地址變化，須要更新集羣全部節點的配置文件後重啓集羣。
二、客戶端submitTopology時也須要取得nimbus ip上傳代碼。nimbus更換機器後，client也須要修改配置文件。
三、nimbus機器的本地硬盤存放了topology的代碼，更換機器後代碼所有丟失，新啓動的supervisor將沒法下載正在運行的topology代碼。
四、storm ui是從nimbus讀取集羣統計信息的，nimbus更換機器後ui也須要修改配置文件後重啓。
五、同時啓動多個nimbus節點，會面臨多個nimbus併發計算topology的任務分配，併發寫入zookeeper，併發清理zookeeper等諸多不可預料的問題。即便存在多個nimbus節點，storm-ui、supervisor、client等也只會使用配置文件指定的ip的節點。

3、nimbus HA 的解決方案

目前topology的jar包保存在nimbus節點的本地存儲上，爲了解決ha的問題，須要提供一種存儲在分佈式而且可靠的方式。DFS是一種完美的解決方案，可是，這不該該是一種強制的使用方式，應該提供可選的可插拔的（默認爲本地文件系統，可是界面應該支持DFS）。若是你選擇本地存儲的方式且嘗試運行多個nimbus，那麼其中一個nimbus應該睡啓動失敗。

Nimbus應該在zookeeper中進行註冊，而後使用leader election protocol來決定哪一個nimbus負責啓動和監控topology。

StormSubmitter應該經過zookeeper找到須要鏈接的nimbus，若是在提交任務期間，leader發生改變，他應該使用retry protocol去嘗試鏈接新的leader並再次嘗試提交任務。

下圖展現了nimbus ha topology做業提交序列圖

leader選舉沒必要多說，基於Zookeeper curator recipes。咱們主要關注下代碼分發，基本流程：

1. leader nimbus經過CodeDistributor上傳代碼並得到MetaFile，而後在Zookeeper建立標記；

2. 非leader nimbus watch到Zookeeper上的變化，從leader得到MetaFile，而後根據MetaFile的描述從CodeDistributor下載代碼。

目前storm1.0.0版本已經將nimbus ha加入。