【09笔记】Storm容错
1、架构容错
-
Zookeeper
存储Nimbus与Supervisor数据
在Supervisor启动时，Supervisor会主动在Zookeeper上注册相应的信息并建立心跳，Nimbus就会发现信息变化以确定新的Supervisor上线了，Nimbus还可以通过心跳对Supervisor管理和监控。
-
节点宕机
因为Nimbus和Supervisor是快速失败和无状态的，所以当节点出现宕机后，不会影响已经提交的任务，只会影响后续任务的提交。
1）Nimbus宕机Supervisor节点还正常运行对应的worker也是正常工运行，只是Supervisor不能接受Nimbus新任务的分配。
2）Supervisor宕机
对应的worker也就挂掉了，但Nimbus节点监控把对应的worker的重新分配到其他的Supervisor节点上运行。
3）Worker出错
因拓扑内存溢出或者其它导致Worker 挂掉，Supervisor会重新启动Worker。
2、数据容错
-
超时
Storm会告知用户每一个消息单元是否在一个指定的时间（timeout）内被完全处理，超时后会杀掉该任务释放资源。 - ack机制
- Storm中每一个Topology中都包含有一个acker组件
- ack本质上是一个或多个task，特殊的task，非常轻量
- 作用：反馈信息和透传
- 消息成功执行后会返回ack，所有的节点ack成功，任务才算成功处理
特殊的Task（Acker Bolt）
- Acker 跟踪每一个spout发出的Tuple树
- 一个Tuple树完成时，发送消息给Tuple的创造者
- Acker 的数量默认是1，如果topology里面的Tuple较多，那么把Acker 的数量设置多一点，效率会高一点
缺点：
- 内存超级大
Acker Task并不显式的跟踪tuple树。 对于那些有成千上万个节点的tuple树，把这么多的tuple信息都跟踪起来会耗费太多的内存。
解决：
- 内存量是恒定的（20bytes，即用20字节代替了tuple树）
- 对于100万tuple，也才20M 左右
- Taskid：ackval
- Ackval所有创建的tupleid/ack的tuple一起异或
一个acker task存储了一个spout-tuple-id到一对值的一个mapping。这个对子的第一个值是创建这个tuple的taskid， 这个是用来在完成处理tuple的时候发送消息用的。 第二个值是一个64位的数字称作：ack val , ack val是整个tuple树的状态的一个表示，不管这棵树多大。它只是简单地把这棵树上的所有创建的tupleid/ack的tupleid一起异或(XOR)。
异或(xor)：
相同为0，不同为1
A:10010 B:01001
A xor B = 11011
A xor A = 0
B xor B = 0
相同两个数据异或结果比是0
对于如下tuple树
- 一个spout，三个bolt
- 初始化ark_val=0
- 每个Tuple都对应有tupleid
- tupleid的值为val_n
- 输出和输入都会进行异或
- 由于输入和输出成对出现，中间不出错的情况下最后结果必为0.
出错时：
- 一个tuple没有ack
解决方法：处理的task挂掉了，超时，重新处理
- Ack挂掉了
解决方法：
- 增加多个ack，利用一致性hash
- 全挂了，超时，重新处理
- Spout挂掉了
解决方法：重新处理