一、前述
Storm容錯機制相比其他的大資料元件做的非常不錯。
二、具體原因
結合Storm叢集架構圖：
我們的程式提交流程如下：
其中各個元件的作用如下：
Nimbus
資源排程
任務分配
接收jar包
Supervisor
接收nimbus分配的任務
啟動、停止自己管理的worker程式（當前supervisor上worker數量由配置檔案設定）
Worker
執行具體處理運算元件的程式（每個Worker對應執行一個Topology的子集）
worker任務型別，即spout任務、bolt任務兩種
啟動executor
（executor即worker JVM程式中的一個java執行緒，一般預設每個executor負責執行一個task任務）
Storm 架構設計與Hadoop架構對比：
當程式提交後，storm的本地配置的目錄架構書如下：
zookeeper目錄樹如下：
因為zookeeper儲存了程式的執行資訊，狀態，並監控task的心跳狀況。所以當程式提交完後，任務資訊都儲存在zookeeper裡面，即使nimbus當機，程式依然會繼續執行。
三、容錯機制
從以下三個方面考慮：
1、叢集節點當機（叢集角度）
Nimbus伺服器
單點故障時可以新增報警，但程式銀鏡載入到記憶體中執行了。
非Nimbus伺服器
故障時，該節點上所有Task任務都會超時，Nimbus會將這些Task任務重新分配到其他伺服器上執行
2、程式掛掉
Worker
掛掉時，Supervisor會重新啟動這個程式。如果啟動過程中仍然一直失敗，並且無法向Nimbus傳送心跳，Nimbus會將該Worker重新分配到其他伺服器上
Supervisor
無狀態（所有的狀態資訊都存放在Zookeeper中來管理）
快速失敗（每當遇到任何異常情況，都會自動毀滅）
Nimbus
無狀態（所有的狀態資訊都存放在Zookeeper中來管理）
快速失敗（每當遇到任何異常情況，都會自動毀滅）
3、訊息的完整性
通過Acker -- 訊息完整性的實現機制
保證訊息肯定能被處理一次，但不保證會不會重複。因為假設發出的是一個values被切割後其中一個被髮送失敗了，那麼這一組values都得重新傳送。
spout傳送的時候同時帶上message_id，這樣這個tuple傳送失敗後，就能知道哪一個tuplele.
通過訊息的亦或狀態確保訊息是否傳送完整。
acker預設為每一個spout，bolt分別啟動一個執行緒。
如下：
