【Storm篇】--Storm 容错机制

一、前述

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