Storm部分：Storm的容错机制

 

 

Storm 的容错机制包括架构容错和数据容错。

1)架构容错：

Nimbus 和 Supervisor 进程被设计成快速失败(fail fast)的(当遇到异常的情况，进程就会挂掉)并且是无状态的(状态都保存在 Zookeeper 或者在磁盘上)。最重要的是，worker 进程不会因为 Nimbus 或者 Supervisor 挂掉而受影响。这跟Hadoop 是不一样的，当 JobTracker 挂掉，所有的任务都会没了。

当 Nimbus 挂掉会怎样？

如果Nimbus是以推荐的方式处于进程监管(例如通过supervisord)之下，那它会被重启，不会有任何影响。

 

否则当 Nimbus 挂掉后：

·已经存在的拓扑可以继续正常运行，但是不能提交新拓扑

·正在运行的 worker 进程仍然可以继续工作。而且当 worker 挂掉，supervisor 会一直重启 worker。

·失败的任务不会被分配到其他机器(是 Nimbus 的职责)上了

当一个 Supervisor(slave 节点)挂掉会怎样？

如果 Supervisor 是以推荐的方式处于进程监管 ( 例如通过 (supervisord)[supervisord.org/])之下，那它会被重启，不会有任何影响

否则当 Supervisor 挂掉：分配到这台机器的所有任务(task)会超时，Nimbus 会把这 些任务(task)重新分配给其他机器。

当一个 worker 挂掉会怎么样？

当一个 worker 挂掉，supervisor 会重启它。如果启动一直失败那么此时worker 也就不能和 Nimbus 保持心跳了，Nimbus 会重新分配 worker 到其他机器。

 

Nimbus 算是一个单点故障吗？

如果 Nimbus节点挂掉，worker 进程仍然可以继续工作。而且当 worker 挂掉， supervisor 会一直重启 worker。但是，没有了 Nimbus，当需要的时候(如果 worker 机器 挂掉了)worker 就不能被重新分配到其他机器了。

所以答案是，Nimbus 在“某种程度”上属于单点故障的。在实际中，这种情况没什么大不了的，因为当 Nimbus 进程挂掉，不会有灾难性的事情发生

2)数据容错：

Storm 中的每一个 Topology 中都包含有一个 Acker 组件。Acker 组件的任务就是跟 踪从某个 task 中的Spout 流出的每一个messageId 所绑定的 Tuple 树中的所有 Tuple 的处理情况 。 如果在用户设置的最大超时时间 （ timetout可以通过 Config.TOPOLOGY_MESSAGE_TIMEOUT_SECS 来指定）内这些 Tuple 没有被完全处理，那么 Acker 会告诉 Spout 该消息处理失败，相反则会告知 Spout 该消息处理成功,它会分别调用 Spout 中的 fail 和 ack 方法。

也就是说acker会跟踪Topology中task的运行，并且还会反馈结果，运行失败了会返回fail。