一、前述
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分别启动一个线程。
如下：
