一、Storm 容错机制
1、集群节点宕机
Nimbus服务器 : 单点故障
非Nimbus服务器 : 故障时，该节点上所有Task任务都会超时，Nimbus会将这些Task任务重新分配到其他服务器上运行。
2、进程挂掉
Worker：挂掉时，Supervisor会重新启动这个进程。如果启动过程中仍然一直失败，并且无法向Nimbus发送心跳，Nimbus会将该Worker重新分配到其他服务器上
Supervisor
无状态（所有的状态信息都存放在Zookeeper中来管理）
快速失败（每当遇到任何异常情况，都会自动毁灭）
Nimbus
无状态（所有的状态信息都存放在Zookeeper中来管理）
快速失败（每当遇到任何异常情况，都会自动毁灭）
3、消息的完整性
如图实例，从Spout中发出的Tuple，以及基于他所产生Tuple（例如上个例子当中Spout发出的句子，以及句子当中单词的tuple等）由这些消息就构成了一棵tuple树。
当这棵tuple树发送完成，并且树当中每一条消息都被正确处理，就表明spout发送消息被“完整处理”，即消息的完整性。
４、Acker -- 消息完整性的实现机制
Storm的拓扑当中特殊的一些任务
负责跟踪每个Spout发出的Tuple的DAG（有向无环图）
默认每个worker一个acker
二、Storm - DRPC介绍
Storm是一个分布式实时处理框架,它支持以DRPC方式调用.可以理解为Storm是一个集群,DRPC提供了集群中处理功能的访问接口。
DRPC设计目的：为了充分利用Storm的计算能力实现高密度的并行实时计算。
DRPC工作流程：
- 客户端发起请求到DRPC Service
- DRPC Service会为这次请求生成对应的requestId与输入的参数一起发送到DRPCSpout，再提交到DrpcTopology(输入参数的字段名称固定为args)
- 处理后的结果返回给ReturnResults
- 调用DRPC Service服务返回给客户端,返回的结果包括requestId和请求的结果数据.
- ReturnResults输出两个字段：第一个为结果数据，第二个为requestId。
工作流程图
三、Storm事务
功能：
将多个tuple组合成为一个批次，并保障每个批次的tuple被且仅被处理一次。
storm事务处理中，把一个批次的tuple的处理分为两个阶段processing和commit阶段。
- processing阶段运行多个批次的tuple并行处理。
- commit阶段各批次之间需强制按照顺序进行提交。
Manages state - 状态管理
把所有实现Transactional Topologies所必须的状态保存在zookeeper里面，包括当前transaction id及定义每个batch的一些元数据。
Coordinates the transactions - 协调事务
决定在任何一个时间点是该proccessing还是该committing。
Fault detection - 故障检测
利用acking框架来高效地检测什么时候一个batch被成功处理了，被成功提交了，或者失败了。Storm然后会相应地replay对应的batch。不需要手动做任何acking或者anchoring (emit时发生的动作)。
Intermediate data cleanup - 中间数据清理
决定什么时候一个bolt接收到一个特定transaction的所有tuple。Storm同时也会自动清理每个transaction所产生的中间数据。