推薦慕課網視頻：http://www.imooc.com/video/10055
另外，關於Storm並發度，已經整理到另一篇博客中，希望對讀者有所幫助。
請參考：http://www.cnblogs.com/quchunhui/p/8271349.html
====Storm的起源。
Storm是開源的、分布式、流式計算系統
什么是分布式呢？就是將一個任務拆解給多個計算機去執行，讓許多機器共通完成同一個任務，
把這個多機的細節給屏蔽，對外提供同一個接口、同一個服務，這樣的系統就是分布式系統。
在多年以前並沒有非常范用的分布式系統，即使存在，也都是限定在指定的領域，
當然，也有人嘗試從中提取出共通的部分，發明一個通用的分布式系統，但是都沒有很好的結果。
后來，Google發表了3篇論文，提出了分布式計算的模型，在分布式系統上有了一個質的突破。
有一位大牛看了這3篇論文之后，深受啟發，然后就發明了Hadoop系統。
然后，基於Hadoop的改造系統就如雨后春筍一般，接二連三的出現了。
以至於，Hadoop已經不是一套軟件，而是一整套生態系統了。
於是，人們談到分布式，就必談Hadoop了。
但是，Hadoop並不是萬能的，它只能處理適合進行批量計算的需求。對於，非批量的計算就不能夠滿足要求了。
很多時候，我們只能先收集一段時間數據，等數據收集到一定規模之后，我們才開始MapReduce處理。
有這么一個故事：
-------------------
路人甲是在一家媒體公司A工作，他的主要工作內容很簡單，就是在一些搜索引擎上做廣告，
眾所周知，搜索引擎上的廣告是競價排名的，誰土豪誰就排前面，出錢少的就只能排在后面。
公司A的競爭對手都比較土豪，所以呢，公司A的廣告就一直排在后面，也沒什么好的辦法。
后來，路人甲想出了一個餿主意，就是用程序不斷的去點擊競爭對手的廣告，讓對手的廣告費
很快的花費調，這樣公司A就可以廉價的將廣告排在前面了。
搜索引擎公司試圖識別出這些惡意點擊屏來保護商家，將這些惡意點擊扣除的費用返還給商家。
一般來說呢，如果利用MapReduce，一般情況下，都需要收集一段時間數據，然后根據這些
數據來算出哪些點擊是惡意的，本身收集數據就已經很耗費時間了，再等計算完畢之后，
土豪商家的廣告費也基本上不剩什么了。
所以呢，我們希望在點擊發生的時候就算出來該點擊是否是作弊行為，即使不能馬上判斷出，
也應該盡早的計算出來。
-------------------
為了解決上面這個故事的需求，分布式流式計算系統就產生了，比較知名的有：
•【Yahoo】S4
•【IBM】StreamBase
•【Amazon】Kinesis
•【Spark】Streaming
•【Google】Millwheel
•【Apache】Storm（目前業界中最知名、流程）
批量計算（以Hadoop為代表）與流式計算的區別有哪些呢？
###################
目前已經有人在做一些前瞻性的項目，這些人試圖將批量計算和流式計算進行整合
試圖使用同一套API，即搞定流式計算，又搞定批量計算。
使一段代碼不要任何改動，就可以同時執行在批量計算和流式計算兩種系統之上。
這種系統目前比較有名的有：
【Twitter】Summing Bird
【Google】CloudDataflow
兩個接口都已經開源了。等以后有機會一定要提前接觸一下。
###################
====Storm組件
Storm采用的是Master-Slave結構，就是使用一個節點來管理整個集群的運行狀態。
Master節點被稱為：Nimbus，Slave節點用來維護每台機器的狀態，被稱為：Supervisor
為什么采取主從結構呢？主從結構比較簡單，不需要進行主節點仲裁等工作。
從前面的結構圖中我們還可以看出，采取主從結構之后，Nimbus是一個單點，
但是，我們知道分布式領域里，大家都比較討厭自己的系統設計中存在單點，
因為單點如果發生故障，很有可能影響到整個集群的可用性。
所以，如果一個系統設計中如果存在單點，一般情況下這個單點的作業必然比較輕，
掛了之后，短時間之內也不影響真個系統的運行，並且一般情況下都是沒有狀態的，
宕機之后至需要重啟就能夠恢復並正確處理。
Nimbus的角色是只負責一些管理性的工作，它並不關心Worker之間的數據是如何傳輸的，
它的一些主要狀態都存在分布式協調服務(Zookeeper)中，內存里面的東西都是可以丟失的，
如果它掛掉，只要沒有運算節點發生故障，那么整個作業還是能夠正常的進行數據處理的。
Nimbus重啟之后，就可以正確處理整個系統的事務了。
Supervisor的角色是聽Nimbus的話，來啟動並監控真正進行計算的Worker的進程，
如果Worker有異常，那么久幫助Worker重啟一下，它也不負責數據計算和數據傳輸，
真正的數據計算和輸出，都是由Worker來進行。
Worker是運行在工作節點上面，被Supervisor守護進程創建的用來干活的JVM進程。
每個Worker對應於一個給定topology的全部執行任務的一個子集。
反過來說，一個Worker里面不會運行屬於不同的topology的執行任務。
====Storm UI
為了方便用戶管理集群，查看集群運行狀態，提供了一個基於Web的UI來監控整個Storm集群
它本身不是集群運行的必須部分，它的啟動停止都不影響Storm的正常運行。
====Storm作業提交運行流程
（1）用戶使用Storm的API來編寫Storm Topology。
（2）使用Storm的Client將Topology提交給Nimbus。
Nimbus收到之后，會將把這些Topology分配給足夠的Supervisor。
（3）Supervisor收到這些Topoligy之后，Nimbus會指派一些Task給這些Supervisor。
（4）Nimvus會指示Supervisor為這些Task生成一些Worker。
（5）Worker來執行這些Task來完成計算任務。
====StormAPI基礎概念
Storm稱用戶的一個作業為Topology（拓撲）。
為什么叫拓撲呢？是因為Storm的一個拓撲主要包含了許多的數據節點，還有一些計算節點，
以及這些節點之間的邊，也就是說Storm的拓撲是由這些點和邊組成的一個有向無環圖。
這些點有兩種：數據源節點（Spout）、普通的計算節點（Bolt），
點之間的邊稱為數據流（Stream），數據流中的每一條記錄稱為Tuple。
如下圖中，每一個“水龍頭”表示一個Spout，它會發送一些Tuple給下游的Bolt，
這些Bolt經過處理周，再發送一個Tuple給下一個Bolt，
最后，在這些Bolt里面是可以執行一些寫數據到外部存儲（如數據庫）等操作的。
在圖中這個Topology里面我們看到了兩個Spout和5個Bolt，
在實際運行的時候，每個Spout節點都可能有很多個實例，每個Bolt也有可能有很多個實例。
就像MapReduce一樣，一個Map節點並不代表只有一個並發，而有可能很多個Map實例在跑。
這些Spout和Bolt的這些邊里面，用戶可以設置多種的Grouping的方式。
有些類似SQL中的Group By。用來制定這些計算是怎么分組的。
*Fields Grouping：保證同樣的字段移動落到同一個Bolt里。
--以WordCount為例，MapReduce和Storm的工作流程對比：
（1）MapReduce
（2）Storm
====各個組件的一些說明
--Topologies
strom jar all-your-code.jar backtype.storm.MyTopology arg1 arg2
--Stream
--數據模型(Data Model)
- public class DoubleAndTripleBoltimplementsIRichBolt {
- private OutputCollectorBase _collector;
- @Override
- public void prepare(Map conf, TopologyContext context, OutputCollectorBase collector) {
- _collector = collector;
- }
- @Override
- public void execute(Tuple input) {
- intval = input.getInteger(0);
- _collector.emit(input,newValues(val*2, val*3));
- _collector.ack(input);
- }
- @Override
- public void cleanup() {
- }
- @Override
- public void declareOutputFields(OutputFieldsDeclarer declarer) {
- declarer.declare(newFields("double","triple"));
- }
- }
參考博客：http://blog.itpub.net/29754888/viewspace-1260026/
====StormAPI使用
我們來看看WorldCount的example代碼。
WordCount的實例：https://github.com/quchunhui/StormWordCount
====Storm的並發機制
Task數量：表示每個Spout或Bolt邏輯上有多少個並發。它影響輸出結果。
Worker數量：代表總共有幾個JVM進程去執行我們的作業。
Executor數量：表示每個Spout或Bolt啟動幾個線程來運行。
下面代碼中的數字表示Executor數量，它不影響結果，影響性能。
Worker的數量在Config中設置，下圖代碼中的部分表示Worker數量。
*本地模式中，Worker數不生效，只會啟動一個JVM進行來執行作業。
*只有在集群模式設置Worker才有效。而且集群模式的時候一定要設置才能體現集群的價值。
====Storm數據可靠性
分布式系統都管理很多台機器，需要保證任意的Worker掛掉之后，我們的系統仍然能正確的處理，那么
Storm如何保證這些數據正確的恢復？
Storm如何保證這些數據不被重復計算？
（1）Spout容錯API：NextTuple中，emit時，指定MsgID。
（2）Bolt容錯API：①emit時，錨定輸入Tuple。②Act輸入Tuple。
====Storm集群搭建
（1）安裝zookeeper集群
配置方法省略。
在storm集群中，zookeeper具體發揮的是什么作用呢？
概括來說，zookeeper是nimbus和supervisor進行交互的中介。
1、nimbus通過在zookeeper上寫狀態信息來分配任務。
通俗的講就是寫哪些supervisor執行哪些task的對應關系。而supervisor則通過從zookeeper上讀取這些狀態信息，來領取任務。
2、supervisor、task會發送心跳到zookeeper，使得nimbus可以監控整個集群的狀態，從而在task執行失敗時，可以重啟他們。
（2）下載安裝Storm
官網上下載Storm：http://storm.apache.org
上傳至Linux並解壓縮。這里將Storm解壓縮到/opt/apache-storm-0.10.0路徑下了。
（3）修改Storm配置文件
配置文件路徑：/opt/apache-storm-0.9.5/conf/storm.yaml
配置內容如下：
----------------
storm.zookeeper.servers:
- "192.168.93.128"
- "192.168.93.129"
- "192.169.93.130"
nimbus.host: "192.168.93.128"
storm.local.dir: "/opt/apache-storm-0.9.5/status"
supervisor.slots.ports:
- 6700
- 6701
- 6702
- 6703
----------------
※storm1.x之后，nimbus配置變更為：解決了nimbus單點故障的問題。
nimbus.seeds: ["192.168.1.80","192.168.1.81"]
置之后的文件如下如所示：
--Storm配置項詳細介紹
•storm.zookeeper.servers：
ZooKeeper服務器列表
•storm.zookeeper.port：
ZooKeeper連接端口
•storm.local.dir：
storm使用的本地文件系統目錄(必須存在並且storm進程可讀寫)
•storm.cluster.mode：
Storm集群運行模式([distributed|local])
•storm.local.mode.zmq：
Local模式下是否使用ZeroMQ作消息系統，如果設置為false則使用java消息系統。默認為false
•storm.zookeeper.root：
ZooKeeper中Storm的根目錄位置
•storm.zookeeper.session.timeout：
客戶端連接ZooKeeper超時時間
•storm.id：
運行中拓撲的id，由storm name和一個唯一隨機數組成。
•nimbus.host：
nimbus服務器地址
•nimbus.thrift.port：nimbus的thrift監聽端口
•nimbus.childopts：
通過storm-deploy項目部署時指定給nimbus進程的jvm選項
•nimbus.task.timeout.secs：
心跳超時時間，超時后nimbus會認為task死掉並重分配給另一個地址
•nimbus.monitor.freq.secs：
nimbus檢查心跳和重分配任務的時間間隔。注意如果是機器宕掉nimbus會立即接管並處理
•nimbus.supervisor.timeout.secs：
supervisor的心跳超時時間，一旦超過nimbus會認為該supervisor已死並停止為它分發新任務
•nimbus.task.launch.secs：
task啟動時的一個特殊超時設置。在啟動后第一次心跳前會使用該值來臨時替代nimbus.task.timeout.secs
•nimbus.reassign：
當發現task失敗時nimbus是否重新分配執行。默認為真，不建議修改
•nimbus.file.copy.expiration.secs：
nimbus判斷上傳/下載鏈接的超時時間，當空閑時間超過該設定時nimbus會認為鏈接死掉並主動斷開
•ui.port：
Storm UI的服務端口
•drpc.servers：
DRPC服務器列表，以便DRPCSpout知道和誰通訊
•drpc.port：
Storm DRPC的服務端口
•supervisor.slots.ports：
supervisor上能夠運行workers的端口列表。每個worker占用一個端口，且每個端口只運行一個worker。
通過這項配置可以調整每台機器上運行的worker數。(調整slot數/每機)
•supervisor.childopts：
在storm-deploy項目中使用，用來配置supervisor守護進程的jvm選項
•supervisor.worker.timeout.secs：
supervisor中的worker心跳超時時間，一旦超時supervisor會嘗試重啟worker進程.
•supervisor.worker.start.timeout.secs：
supervisor初始啟動時，worker的心跳超時時間，當超過該時間supervisor會嘗試重啟worker。
因為JVM初始啟動和配置會帶來的額外消耗，從而使得第一次心跳會超過supervisor.worker.timeout.secs的設定
•supervisor.enable：
supervisor是否應當運行分配給他的workers。默認為true，該選項用來進行Storm的單元測試，一般不應修改.
•supervisor.heartbeat.frequency.secs：
supervisor心跳發送頻率(多久發送一次)
•supervisor.monitor.frequency.secs：
supervisor檢查worker心跳的頻率
•worker.childopts：
supervisor啟動worker時使用的jvm選項。所有的”%ID%”字串會被替換為對應worker的標識符
•worker.heartbeat.frequency.secs：
worker的心跳發送時間間隔
•task.heartbeat.frequency.secs：
task匯報狀態心跳時間間隔
•task.refresh.poll.secs：
task與其他tasks之間鏈接同步的頻率。(如果task被重分配，其他tasks向它發送消息需要刷新連接)
。一般來講，重分配發生時其他tasks會理解得到通知。該配置僅僅為了防止未通知的情況。
•topology.debug：
如果設置成true，Storm將記錄發射的每條信息。
•topology.optimize：
master是否在合適時機通過在單個線程內運行多個task以達到優化topologies的目的
•topology.workers：
執行該topology集群中應當啟動的進程數量。
每個進程內部將以線程方式執行一定數目的tasks。topology的組件結合該參數和並行度提示來優化性能
•topology.ackers：
topology中啟動的acker任務數。
Acker保存由spout發送的tuples的記錄，並探測tuple何時被完全處理。
當Acker探測到tuple被處理完畢時會向spout發送確認信息。通常應當根據topology的吞吐量來確定acker的數目，但一般不需要太多。
當設置為0時，相當於禁用了消息可靠性。storm會在spout發送tuples后立即進行確認
•topology.message.timeout.secs：
topology中spout發送消息的最大處理超時時間。
如果一條消息在該時間窗口內未被成功ack，Storm會告知spout這條消息失敗。而部分spout實現了失敗消息重播功能。
•topology.kryo.register：
注冊到Kryo(Storm底層的序列化框架)的序列化方案列表。序列化方案可以是一個類名，或者是com.esotericsoftware.kryo.Serializer的實現
•topology.skip.missing.kryo.registrations：
Storm是否應該跳過它不能識別的kryo序列化方案。如果設置為否task可能會裝載失敗或者在運行時拋出錯誤
•topology.max.task.parallelism：
在一個topology中能夠允許的最大組件並行度。該項配置主要用在本地模式中測試線程數限制.
•topology.max.spout.pending：
一個spout task中處於pending狀態的最大的tuples數量。該配置應用於單個task，而不是整個spouts或topology
•topology.state.synchronization.timeout.secs：
組件同步狀態源的最大超時時間(保留選項,暫未使用)
•topology.stats.sample.rate：
用來產生task統計信息的tuples抽樣百分比
•topology.fall.back.on.java.serialization：
topology中是否使用java的序列化方案
•zmq.threads：
每個worker進程內zeromq通訊用到的線程數
•zmq.linger.millis：
當連接關閉時，鏈接嘗試重新發送消息到目標主機的持續時長。這是一個不常用的高級選項，基本上可以忽略.
•java.library.path：
JVM啟動(如Nimbus,Supervisor和workers)時的java.library.path設置。該選項告訴JVM在哪些路徑下定位本地庫
（4）配置Storm環境變量
環境變量位置：/etc/profile
配置內容之后如下圖所示：
注意：環境變量修改只有，一定要使用Source命令來使之生效。
（5）啟動Storm
--啟動Storm UI
命令：storm ui >/dev/null 2>&1 &
我們可以它啟動的時候相關的輸出指向到/def/null，並且把錯誤也重新定向到正常輸出。
--啟動主節點（Nimbus節點）
命令：storm nimbus >/dev/null 2>&1 &
在第1台Linux虛擬機上執行。正常啟動時的jps結果如下圖所示：
--啟動工作節點（Supervisor節點）
命令：storm supervisor >/dev/null 2>&1 &
在第2、3台Linux虛擬機上執行。正常啟動時的jps結果如下圖所示：
（6）啟動StormUI監控頁面：
Storm正常啟動之后，應該可以打開StormUI畫面。在瀏覽器中輸入地址和端口即可
正確啟動時應該如下圖所示：
--Mainpage：
main頁面主要包括3個部分
【Cluster Summary】
•Nimbus uptime: nimbus的啟動時間
•Supervisors: storm集群中supervisor的數目
•used slots: 使用了的slots數
•free slots: 剩余的slots數
•total slots: 總的slots數
•Running tasks: 運行的任務數
【topology summary】
•Name: topology name
•id: topology id (由storm生成)
•status: topology的狀態，包括(ACTIVE, INACTIVE, KILLED, REBALANCING)
•uptime: topology運行的時間
•num workers: 運行的workers數
•num tasks: 運行的task數
【supervisor summary】
•host: supervisor(主機)的主機名
•uptime: supervisor啟動的時間
•slots: supervisor的端口數
•used slots: 使用的端口數
--Topology page
topology頁面主要包括4個部分
【topology summary】
(同主頁)
【topology stats】
•window: 時間窗口，顯示10m、3h、1d和all time的運行狀況
•emitted: emitted tuple數
•transferred: transferred tuple數, 說下與emitted的區別：如果一個task，emitted一個tuple到2個task中，則transferred tuple數是emitted tuple數的兩倍
•complete latency: spout emitting 一個tuple到spout ack這個tuple的平均時間
•acked: ack tuple數
•failed: 失敗的tuple數
【spouts】
•id: spout id
•parallelism: 任務數
•last error: 最近的錯誤數，只顯示最近的前200個錯誤
•emitted、transferred、complete latency、acked和failed上面已解釋
【bolts】
•process latency: bolt收到一個tuple到bolt ack這個tuple的平均時間
其他參數都解釋過了
還有componentpage和taskpage，參數的解釋同上。
taskpage中的Component指的是spoutid或者boltid，time指的是錯誤發生的時間，error是指錯誤的具體內容。
====Storm常用命令
【提交Topologies】
命令格式：storm jar 【jar路徑】 【拓撲包名.拓撲類名】 【拓撲名稱】
樣例：storm jar /storm-starter.jar storm.starter.WordCountTopology wordcountTop
#提交storm-starter.jar到遠程集群，並啟動wordcountTop拓撲。
【停止Topologies】
命令格式：storm kill 【拓撲名稱】
樣例：storm kill wordcountTop
#殺掉wordcountTop拓撲。
【啟動nimbus后台程序】
命令格式：storm nimbus
【啟動supervisor后台程序】
命令格式：storm supervisor
【啟動drpc服務】
命令格式：storm drpc
【啟動ui服務】
命令格式：storm ui
【啟動REPL】
REPL — read-evaluate-print-loop。
雖然clojure可以作為一種腳本語言內嵌在java里面，但是它的首選編程方式是使用REPL，這是一個簡單的命令行接口，
使用它你可以輸入你的命令，執行，然后查看結果， 你可以以下面這個命令來啟動REPL：
命令格式：storm repl
【打印本地配置】
命令格式：storm localconfvalue [配置參數關鍵字]
舉例：storm localconfvalue storm.zookeeper.servers
#根據指定參數打印本地配置的值。
【打印遠程配置】
命令格式：storm remoteconfvalue [配置參數關鍵字]
舉例：storm remoteconfvalue storm.zookeeper.servers
#根據指定參數打印遠程配置的值。
【執行Shell腳本】
命令格式：storm shell resourcesdir command args
【打印CLASSPATH】
命令格式：storm classpath
====Storm調優：
--調優對象
當一個topology在storm cluster中運行時，它的並發主要跟3個邏輯對象相關：worker => executor =>task。(=>代表1對N)
（1）Worker
Worker是運行在工作節點上面，被Supervisor守護進程創建的用來干活的JVM進程。
每個Worker對應於一個給定topology的全部執行任務的一個子集。
反過來說，一個Worker里面不會運行屬於不同的topology的執行任務。
它可以通過[storm rebalance]命令任意調整。
（2）Executor
可以理解成一個Worker進程中的工作線程。
一個Executor中只能運行隸屬於同一個component（spout/bolt）的task。
一個Worker進程中可以有一個或多個Executor線程。在默認情況下，一個Executor運行一個task。
每個component（spout/bolt）的並發度就是指executor數量。
它可以通過[storm rebalance]命令任意調整。
（3）Task
Task則是spout和bolt中具體要干的活了。一個Executor可以負責1個或多個task。
同時，task也是各個節點之間進行grouping（partition）的單位。無法在運行時調整。
--設置方法：
conf.setNumWorkers(workers); //設置worker數量
uilder.setBolt("2", new WordSpliter(),4) //設置Executor並發數量
builder.setBolt("2", new WordSpliter(),4).setNumTasks(1); //設置每個線程處理的Task數量
--任務分配：
任務分配是有下面兩種情況：
①、task數目比worker多：
例如task是[1 2 3 4]，可用的slot(所謂slot就是可用的worker)只有[host1:port1，host2:port1]，那么最終是這樣分配
1：[host1:port1]
2：[host2:port1]
3：[host1:port1]
4：[host2:port1]
②、task數目比worker少：
例如task是[1 2]，而worker有[host1:port1，host1:port2，host2:port1，host2:port2]，
那么首先會將woker排序，將不同host間隔排列，保證task不會全部分配到同一個機器上，也就是將worker排列成
[host1:port1，host2:port1，host1:port2，host2:port2]
然后分配任務為：
1：[host1:port1]
2：[host2:port1]
--簡單舉例：
通過Config.setNumWorkers(int))來指定一個storm集群中執行topolgy的進程數量，所有的線程將在這些指定的worker進程中運行。
比如說一個topology中要啟動300個線程來運行spout/bolt，而指定的worker進程數量是60個。
那么storm將會給每個worker分配5個線程來跑spout/bolt。
如果要對一個topology進行調優，可以調整worker數量和spout/bolt的parallelism(並發度，即executor)數量。
(調整參數之后要記得重新部署topology，后續會為該操作提供一個swapping的功能來減小重新部署的時間)。
例如：
builder.setBolt("cpp", new CppBolt(), 3).setNumTasks(5).noneGrouping(pre_name);
會創建3個線程，但有內存中會5個CppBolt對象，3個線程調度5個對象。
--網上搜羅的一些經驗：
①、對於worker和task之間的比例，網上也給出了參考,。即1個worker包含10~15個左右。當然這個參考，實際情況還是要根據配置和測試情況。
②、executor數最大不能超過該bolt的task數。
--Strom集群命令
[root@h2master bin]# storm
Commands:
activate
classpath
deactivate
dev-zookeeper
drpc
help 命令幫助
jar 執行上傳的jar包
kill 殺死正在執行的topology 后面跟 topology的名稱
list 查看運行的所有topology運行情況
localconfvalue
logviewer 啟動topology日志
nimbus 啟動nimbus
rebalance shell方式下修改topology運行參數比如worker個數 task個數等
remoteconfvalue
repl
shell
supervisor 啟動supervisor
ui 啟動topology ui界面
version
Help:
help
help <command>
- [root@h2master bin]# storm
- Commands:
- activate
- classpath
- deactivate
- dev-zookeeper
- drpc
- help 命令幫助
- jar 執行上傳的jar包
- kill 殺死正在執行的topology 后面跟 topology的名稱
- list 查看運行的所有topology運行情況
- localconfvalue
- logviewer 啟動topology日志
- nimbus 啟動nimbus
- rebalance shell方式下修改topology運行參數比如worker個數 task個數等
- remoteconfvalue
- repl
- shell
- supervisor 啟動supervisor
- ui 啟動topology ui界面
- version
- Help:
- help
- help <command>
----Storm高可用HA
關於Storm的高可用，有以下幾個方面：
(1)數據利用階段可以通過ACK機制保證數據被處理；
(2)在進程級別，worker失效，supervisor會自動重啟worker線程;
(3)在組件級別，supervisor節點失效，會在其他節點重啟該supervisor任務；
但是，nimbus節點失效怎么辦？
Supervisor進程和Nimbus進程，需要用Daemon程序如monit來啟動，失效時自動重新啟動。
如果Nimbus進程所在的機器都直接倒了，需要在其他機器上重新啟動，Storm目前沒有自建支持，需要自己寫腳本實現。
即使Nimbus進程不在了，也只是不能部署新任務，有節點失效時不能重新分配而已，不影響已有的線程。
同樣，如果Supervisor進程失效，不影響已存在的Worker進程。
--END--