Storm的容错性

一、简介

　　如果在消息处理过程中出了一些异常，Storm 会重新安排这个出问题的 topology。Storm 保证一个 topology 永远运行（除非你显式杀掉这个 topology） 。

　　当然，如果 topology 中存储了中间状态，那么当 topology 重新被 Storm 启动的时候，需要应用自己处理中间状态的恢复

二、集群的各级容错

1. 任务级失败

1. bolt 任务失败。此时，acker 中所有与此 bolt 任务关联的消息都会因为超时而失败，对应 spout 的 fail 方法将被调用。
2. acker 任务失败。如果 acker 任务本身失败了，它在失败之前持有的所有消息都将会因为超时而失败。Spout 的 fail 方法将被调用。
3. Spout 任务失败。这种情况下，Spout 任务对接的外部设备（如MQ）负责消息的完整性。例如当客户端异常的情况下，kestrel队列会将处于 pending 状态的所有的消息重新放回到队列中。其他的 spout 数据源，可能需要我们自行维护这个消息的完整性

2. 任务槽(slot)故障

1. worker 失败。每个 worker 中包含数个 bolt（或 spout）任务 。supervisor 负责监控这些任务，当 worker 失败后，supervisor会尝试在本机重启它。
2. supervisor 失败。supervisor 是无状态的，因此 supervisor 的失败不会影响当前正在运行的任务，只要及时的将它重新启动即可。supervisor 不是自举的，需要外部监控来及时重启。
3. nimbus 失败。nimbus 是无状态的，因此 nimbus 的失败不会影响当前正在运行的任务（nimbus 失败时，无法提交新的任务） ，只要及时的将它重新启动即可。nimbus 不是自举的 ， 需要外部监控来及时重启

3. 集群节点（机器）故障　　

1. storm 集群中的节点故障。此时 nimbus 会将此机器上所有正在运行的任务转移到其他可用的机器上运行。
2. zookeeper 集群中的节点故障。 zookeeper 保证少于半数的机器宕机仍可正常运行，及时修复故障机器即可