【Storm篇】--Storm 容错机制

=========================================================


声明：由于不同平台阅读格式不一致(尤其源码部分)，所以获取更多阅读体验！！

请关注本人博客园地址：http://www.cnblogs.com/LHWorldBlog/

个人网站地址：http://www.lhworldblog.com/

==========================================================

一、前述

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分别启动一个线程。

如下：