一、前述

Storm容错机制相比其他的大数据组件做的非常不错。

二、具体原因

结合Storm集群架构图：

我们的程序提交流程如下：

 

 

其中各个组件的作用如下：

Nimbus

资源调度

任务分配

接收jar包

Supervisor

接收nimbus分配的任务

启动、停止自己管理的worker进程（当前supervisor上worker数量由配置文件设定）

Worker

运行具体处理运算组件的进程（每个Worker对应执行一个Topology的子集）

worker任务类型，即spout任务、bolt任务两种

启动executor

    （executor即worker JVM进程中的一个java线程，一般默认每个executor负责执行一个task任务）

 

Storm 架构设计与Hadoop架构对比：

 

当程序提交后，storm的本地配置的目录架构书如下：

zookeeper目录树如下：

因为zookeeper存储了程序的运行信息，状态，并监控task的心跳状况。所以当程序提交完后，任务信息都存储在zookeeper里面，即使nimbus宕机，程序依然会继续执行。

三、容错机制

从以下三个方面考虑：

1、集群节点宕机（集群角度）

Nimbus服务器

单点故障时可以添加报警，但程序银镜加载到内存中运行了。

非Nimbus服务器

故障时，该节点上所有Task任务都会超时，Nimbus会将这些Task任务重新分配到其他服务器上运行

2、进程挂掉

Worker

挂掉时，Supervisor会重新启动这个进程。如果启动过程中仍然一直失败，并且无法向Nimbus发送心跳，Nimbus会将该Worker重新分配到其他服务器上

Supervisor

无状态（所有的状态信息都存放在Zookeeper中来管理）

快速失败（每当遇到任何异常情况，都会自动毁灭）

Nimbus

无状态（所有的状态信息都存放在Zookeeper中来管理）

快速失败（每当遇到任何异常情况，都会自动毁灭）

3、消息的完整性

通过Acker -- 消息完整性的实现机制

保证消息肯定能被处理一次，但不保证会不会重复。因为假设发出的是一个values被切割后其中一个被发送失败了，那么这一组values都得重新发送。

spout发送的时候同时带上message_id，这样这个tuple发送失败后，就能知道哪一个tuplele.

通过消息的亦或状态确保消息是否发送完整。

acker默认为每一个spout，bolt分别启动一个线程。

如下：