Storm系統高可用性HA表現

　　關於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項目。

 

 

推薦連接：

一、Fault Tolerance —— Storm的故障容錯性　

—— 本文講解了Storm故障容忍性(Fault-Tolerance)的設計細節：當Worker、節點、Nimbus或者Supervisor出現故障時是如何實現故障容忍性，以及Nimbus是否存在單點故障問題。

二、storm源碼之一個class解決nimbus單點問題【轉】

本文導讀：
1 storm nimbus 單節點問題概述
2 storm與解決nimbus單點相關的概念
3 nimbus目前沒法作到多節點的緣由
4 解決nimbus單點問題的關鍵
5 業界對nimbus單點問題的努力
6 nimbus單點問題的解決思路
7 NimbusCloudStorage的實現
8 總結：