Storm容錯機制

1.bolt任務crash引起的訊息未被應答。此時，acker中所有與此bolt任務關聯的訊息都會因為超時而失敗，對應的spout的fail方法將被呼叫。

2.acker任務失敗。如果acker任務本身失敗了，它在失敗之前持有的所有訊息都將超時而失敗。spout的fail方法將被呼叫。

3.spout任務失敗。在這種情況下，與spout任務對接的外部裝置(如mq)負責訊息的完整性。例如，當客戶端異常時，kestrel佇列會將處於pending狀態的所有訊息重新放回佇列中。

1.worker失敗。每個worker中包含數個bolt(或spout)任務。supervisor負責監控這些任務，當worker失敗後會嘗試在本機重啟它，如果它在啟動時連續失敗了一定的次數，無法傳送心跳資訊到nimbus，nimbus將在另一台主機上重新分配worker。

2.supervisor失敗。supervisor是無狀態(所有的狀態都儲存在zookeeper或者磁碟上)和快速失敗(每當遇到任何意外的情況，程序自動毀滅)的，因此supervisor的失敗不會影響當前正在執行的任務，只要及時將他們重新啟動即可。

3.nimbus失敗。nimbus也是無狀態和快速失敗的，因此nimbus的失敗不會影響當前正在執行的任務，但是當nimbus失敗時，無法提交新的任務，只要及時將它重新啟動即可。

1.storm集群中的節點故障。此時nimbus會將此機器上所有正在執行的任務轉移到其他可用的機器上執行。

2.zookeeper集群中的節點故障。zookeeper保證少於半數的機器宕機系統仍可正常執行，及時修復故障機器即可。

nimbus是否是「單點故障」的

如果失去了nimbus節點，worker也會繼續執行。另外，如果worker死亡，supervisor也會繼續重啟他們。但是，沒有nimbus，worker不會在必要時(例如，失去乙個worker的主機)被安排到其他主機，客戶端也無法提交任務。

所以nimbus「在某種程度上」是單點故障。在實踐中，這不是乙個大問題，因為nimbus守護程序死亡，不會發生災難性問題。