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

这篇博客的内容是关于Storm官网上的Fault-Tolerance文章的翻译。一直在关注Storm相关的技术，发现官网上这篇文章虽然字数很少，但却描述了Storm故障容忍性的主要设计细节（除了保证数据处理这一块，已经在Guaranteeing
message processing文章中中详细讲解，所以文中只是给了一个link)。

当一个Worker挂了会怎样？

当一个Worker挂了，Supervisor会重启它。如果这个Worker连续在启动时失败，并且无法让Nimbus观察到它的心跳，Nimbus将这个Worker重新分配到另一台机器上。

当一个节点挂了会怎样？

分配给这台机器的任务将会超时，并且Nimbus将这些任务重新分配给其它机器。

当Nimbus或者Supervisor daemon进程挂了会怎样？

Nimbus和Supervisor daemon进程设计成快速失败(无论何时当遇到任何异常情况，将会执行自毁)和无状态（所有的状态都保存在Zookeeper或者磁盘上）。正如Setting up a Storm cluster中描述的，Nimbus和Supervior daemon进程必须在监控下运行，如使用daemontools或者monit工具。所以如果Nimbus或者Supervisor
daemon进程挂了，它可以像什么异常也没有发生似的重新启动。

非常重要的是，没有任何Worker进程会因Nimbus或者Supervisor的挂掉而受到影响。这个和Hadoop相反。在Hadoop中如果JobTracker挂了，所有运行的Job将会丢失。

Nimbus是否有单点故障？

当你丢失了Nimbus节点，Worker将依然可以继续工作。此外，Supervisor将可以继续重启挂掉的Worker。然而，没有了Nimbus节点，Worker不能在需要的时候被重新分配到其它的机器。（例如你丢失了一台Woker机器)。

所以答案是Nimbus是会有单点故障的问题。在实践中，这个不是大问题。Nimbus deamon进程挂掉不会引起任何灾难发生。在将来，计划将Nimbus设计成高可用。

Storm如何保证数据处理?

Storm提供了一些机制来保证即使在节点挂了或者消息被丢失的情况下也能正确的进行数据处理。可以参考 Guaranteeing message processing。