关于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 总结：