前述：
本章內(nèi)容借鑒官文和一些資料，有問題的地方希望大家指出。同樣，內(nèi)容中不會給出部署Storm集群的方法和步驟，因為部署只是我們使用它的基礎(chǔ)，個人認為集群部署維護屬于運維層面；也不會詳解Command line client；更不會貼出yaml配置文件。所以不包含上述內(nèi)容，希望不會浪費到大家時間。
那文章內(nèi)容會有什么呢？
在完成上述工作以后，卻不理解Storm是如何通過storm.yaml這個文件進行工作，集群之間是如何運行、每個守護進程都做了什么、代碼怎么分配到每個節(jié)點、Storm的代碼邏輯怎么寫才會符合Stream、如何Storm集成到其他系統(tǒng)中、甚至想要重編譯Storm；通過了解以下內(nèi)容，可以理解并解決剛才的問題，舉一反三。
當(dāng)然這個必須自己部署一遍，熟悉過程，因為后期的topology結(jié)構(gòu)定義可以不用寫入代碼內(nèi)，而走flux配置來完成。這意味這什么呢？
概念：
特點介紹：
Storm 采用云計算框架中最實用的master/slave結(jié)構(gòu)，靜態(tài)設(shè)置。
主節(jié)點為nimbus，半容錯；從節(jié)點supervisor；中間關(guān)系通過Zookeeper維護。
半容錯：由于Nimbus不參與數(shù)據(jù)處理過程，且topology不會自動停止。所以只能對topology初始化、任務(wù)分發(fā)和監(jiān)控，不會影響任務(wù)處理過程。但如果supervisor掛掉，nimbus不能再重新指派任務(wù)。
當(dāng)然，可以使用HA nimbus，這個我們以后談###############。
進程組件：
如果大家還記得上一章的Storm框架嗎？本章就是圍繞該架構(gòu)來分析機理，首先，來看下每個進程組件的功能。
Nimbus：
Nimbus守護進程主要負責(zé)管理（類似于namenode+ResourceManager，因為Storm不需要hdfs），協(xié)調(diào)+監(jiān)控 = topology的發(fā)布、任務(wù)指派、失敗重新指派等。
Nimbus會記錄所有supervisor節(jié)點的狀態(tài)和分配給它們的task；如果supervisor沒有heartbeat或不可達，它會將故障supervisor中的task重新分配到其他節(jié)點。
Supervisor：
Supervisor守護進程等待nimbus分配任務(wù)后，生成并監(jiān)控workers（JVM進程）的執(zhí)行。
Supervisor和worker都是運行在不同的JVM進程上（一個節(jié)點上可以運行多個JVM，每個JVM為一個進程，即worker），worker失敗是由supervisor重啟。
保障傳輸機制：當(dāng)打開了可靠傳輸選項，傳輸?shù)焦收瞎?jié)點的tuple將不會收到應(yīng)答確認，spout會因為超時而重新發(fā)射原始tuple（問題5），直到topology從故障中回復(fù)開始正常處理數(shù)據(jù)。
Zookeeper：
Storm 主要使用ZooKeeper 來協(xié)調(diào)一個集群中的狀態(tài)信息，比如任務(wù)的分配情況，worker的狀態(tài)，supervisor之間的nimbus的拓撲度量。nimbus 和supervisor節(jié)點之間的通信主要是結(jié)合 ZooKeeper 的狀態(tài)變更通知和監(jiān)控通知來處理的。（Zookeeper的在集群中最重要的應(yīng)用?。?a target="_blank" rel="nofollow">1、Zookeeper原理、結(jié)構(gòu)——Kuring 經(jīng)典
Thrift：
對于重量級的數(shù)據(jù)傳輸操作，比如發(fā)布topology 時傳輸jar 包，Storm 依賴Thirft 進行通信。（在以后的源碼分析中會有詳解）
在理解每個守護進程后，我們來看看他們之間是如何工作的。
集群運行機制：
Storm的集群主要由三部分組成：nimbus、zookeeper、supervisor。
master是不會與每個slaver直接通信，他們之間的交流是通過zk，其中包括：代碼下載、心跳機制、任務(wù)分配、同步集群等等。
這里簡單提一下zk的主要功能：1、同步少量數(shù)據(jù)。2、有監(jiān)聽觸發(fā)機制。
感興趣的朋友可以自行學(xué)習(xí)zk，這里默認大家使用過zk。
nimbus的元數(shù)據(jù)存儲在zk中，由于supervisor并不會直接與其通信，所以才會有半容錯的存在。
1、實際上，nimbus在獲取代碼后運行代碼，解析配置和topology結(jié)構(gòu)，得到需要分配多少worker、executor、task等等，topology運行時需要的資源。
2、把相關(guān)信息提交給zk。這里其實就是修改zk中的tree文件內(nèi)容，至于zk中的Storm tree是什么樣的接下來會講到。
3、zk作為中間服務(wù)系統(tǒng)，會觸發(fā)消息到對應(yīng)的supervisor。
4、每個supervisor得到信息后，會根據(jù)信息分配資源，首先是worker的建立、開啟多少個executor、提交對應(yīng)的tasks。
至于并發(fā)度、并行度，這些在提交代碼、配置時已經(jīng)定義好了，不用多說，如何做到這點請參考上一章Storm概念、原理詳解及其應(yīng)用（一）BaseStorm
zookeeper：
Storm在zookeeper中生成的樹型目錄結(jié)構(gòu)如下圖：
可以看出，根目錄為/storm，其下的每一個葉子目錄都是Storm存儲元數(shù)據(jù)的地方。
下面分別介紹ZooKeeper中每項數(shù)據(jù)的具體含義：
/storm/workerbeats/<topology-id>/node-port：它存儲由node和port指定的Worker的運行狀態(tài)和一些統(tǒng)計信息，主要包括storm-id（也即topology-id）、當(dāng)前Worker上所有Executor的統(tǒng)計信息（如發(fā)送的消息數(shù)目、接收的消息數(shù)目等）、當(dāng)前Worker的啟動時間以及最后一次更新這些信息的時間。在一個topology-id下面，可能有多個node-port節(jié)點。它的內(nèi)容在運行過程中會被更新。
/storm/storms/<topology-id>：它存儲Topology本身的信息，包括它的名字、啟動時間、運行狀態(tài)、要使用的Worker數(shù)目以及每個組件的并行度設(shè)置。它的內(nèi)容在運行過程中是不變的。
/storm/assignments/<topology-id>：它存儲了Nimbus為每個Topology分配的任務(wù)信息，包括該Topology在Nimbus機器本地的存儲目錄、被分配到的Supervisor機器到主機名的映射關(guān)系、每個Executor運行在哪個Worker上以及每個Executor的啟動時間。該節(jié)點的數(shù)據(jù)在運行過程中會被更新。
/storm/supervisors/<supervisor-id>：它存儲Supervisor機器本身的運行統(tǒng)計信息，主要包括最近一次更新時間、主機名、supervisor-id、已經(jīng)使用的端口列表、所有的端口列表以及運行時間。該節(jié)點的數(shù)據(jù)在運行過程中也會被更新。
/storm/errors/<topology-id>/<component-id>/e<sequential-id>：它存儲運行過程中每個組件上發(fā)生的錯誤信息。<sequential-id>是一個遞增的序列號，每一個組件最多只會保留最近的10條錯誤信息。它的內(nèi)容在運行過程中是不變的（但是有可能被刪除）。
轉(zhuǎn)自:https://blog.csdn.net/kuring_k/article/details/51887340
