關於Storm的高可用，有以下幾個方面：
(1)數據利用階段可以通過ACK機制保證數據被處理；
(2)在進程級別，worker失效，supervisor會自動重啟worker線程;
(3)在組件級別，supervisor節點失效，會在其他節點重啟該supervisor任務；
但是一個很大的問題，nimbus節點失效怎么辦？
Supervisor進程和Nimbus進程，需要用Daemon程序如monit來啟動，失效時自動重新啟動。
因為它們在進程內都不保存狀態，狀態都保存在本地文件和ZooKeeper，因此進程可以隨便殺。
如果Nimbus進程所在的機器都直接倒了，需要在其他機器上重新啟動，Storm目前沒有自建支持，需要自己寫腳本實現。
即使Nimbus進程不在了，也只是不能部署新任務，有節點失效時不能重新分配而已，不影響已有的線程。
同樣，如果Supervisor進程失效，不影響已存在的Worker進程。
Zookeeper本身已經是按至少三台部署的HA架構了。
目前storm是不支持nimbus高可用的。關於nimbus的重要性，在拓撲任務開始階段，負責將任務提交到集群，后期負責拓撲任務的管理，比如任務查看，終止等操作。在通常情況下，nimbus的任務壓力並不會很大，在自然情況下不會出現宕機的情況，但在自然因素下nimbus宕機，這種情況下怎么保證高可用？
雖然nimbus重啟，對任務並沒有影響。
目前storm官方或許是出於nimbus宕機對集群影響不大的考慮，並沒有在這方面有所進展。
但還是有人在這方面進行了嘗試，可以參考一下這個GitHub項目。
推薦鏈接：
1、Fault Tolerance —— Storm的故障容錯性
—— 本文講解了Storm故障容忍性(Fault-Tolerance)的設計細節：當Worker、節點、Nimbus或者Supervisor出現故障時是如何實現故障容忍性，以及Nimbus是否存在單點故障問題。
2、storm源碼之一個class解決nimbus單點問題【轉】
本文導讀：
1 storm nimbus 單節點問題概述 2 storm與解決nimbus單點相關的概念 3 nimbus目前無法做到多節點的原因 4 解決nimbus單點問題的關鍵 5 業界對nimbus單點問題的努力 6 nimbus單點問題的解決思路 7 NimbusCloudStorage的實現 8 總結：