【Storm篇】--Storm 容錯機制
一、前述
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分別啟動一個線程。
如下：
【Storm篇】--Storm 容錯機制