Storm容错机制

任务级失败

1.Bolt任务crash引起的消息未被应答。此时，acker中所有与此Bolt任务关联的消息都会因为超时而失败，对应的Spout的fail方法将被调用。

2.acker任务失败。如果acker任务本身失败了，它在失败之前持有的所有消息都将超时而失败。Spout的fail方法将被调用。

3.Spout任务失败。在这种情况下，与Spout任务对接的外部设备(如MQ)负责消息的完整性。例如，当客户端异常时，kestrel队列会将处于pending状态的所有消息重新放回队列中。

任务槽(slot)故障

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守护进程死亡，不会发生灾难性问题。

附：文章引用自《从零开始学Storm》、《Storm实战-构建大数据实时计算》