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项目。

推荐链接：

1、Fault Tolerance —— Storm的故障容错性　

—— 本文讲解了Storm故障容忍性(Fault-Tolerance)的设计细节：当Worker、节点、Nimbus或者Supervisor出现故障时是如何实现故障容忍性，以及Nimbus是否存在单点故障问题。

2、storm源码之一个class解决nimbus单点问题【转】

本文导读：
1 storm nimbus 单节点问题概述
 storm与解决nimbus单点相关的概念
 nimbus目前无法做到多节点的原因
 解决nimbus单点问题的关键
 业界对nimbus单点问题的努力
 nimbus单点问题的解决思路
 NimbusCloudStorage的实现
 总结：