storm的acker机制

一、简介：

storm中有一个很重要的特性：
保证发出的每个tuple都会被完整处理。一个tuple被完全处理的意思是： 这个tuple以及由这个tuple所产生的所有的子tuple都被成功处理。如果任一个消息在timeout所指定的时间内没有完成处理，那这个tuple就失败了。

二、原理：

acker并不会为每个tuple都分配内存空间来完成跟踪，而是利用了一个非常巧妙的算法，这个算法只需使用恒定的20字节就可以完成整个tuple树的跟踪。

具体原理：

acker对于每个spout-tuple保存一个ack-val的校验值，它的初始值是0，然后每发射一个tuple/ack一个tuple，那么tuple的id都要跟这个校验值异或一下，
并且把得到的值更新为ack-val的新值。那么假设每个发射出去的tuple都被ack了，那么最后ack-val一定是0(因为一个数字跟自己异或得到的值是0)。

通俗理解：

1. 在spout产生一条tuple时，会向acker发送一条信息，让ack来进行跟踪

消息内容：{spout-tuple-id {:spout-task task-id :val ack-val}}
spout-tuple-id：这条tuple的id,每条tuple都会产生一个随机的MessageId
task-id：产生这条tuple的id，spout可能有多个task，每个task都会被分配一个唯一的taskId
ack-val：默认值为0，用来跟踪tuple

2. acker会在自己的map(类型为TimeCacheMap)里保存这条记录。这就是acker对spout-tuple进行跟踪的核心数据结构，对于每个spout-tuple所产生的tuple树的跟踪
都只需要保存上面这条记录。acker后面会检查:val什么时候变成0，变成0，说明这个spout-tuple产生的tuple都处理完成了。

3. spout在发送完消息给acker后会将该tuple和MessageId发送到boltTask。boltTask在创建子tuple时并不会向acker发送消息让其跟踪，而是很巧妙的省略了这一步。
bolt在发射一个新的bolt的时候会把这个新tuple跟它的父tuple的关系保存起来(strom称之为anchoring)。然后在ack tuple的时候，storm会把要ack的tuple的id, 以及这个tuple新创建的所有的tuple的id的异或值发送给acker。消息格式是:(spout-tuple-id,tmp-ack-val)执行完这一步后，ack-val的值就变成了所有子tuple的id的异或值
ps:storm使用一致性哈希来把一个spout-tuple-id对应到acker，因为每一个tuple知道它所有的祖宗的tuple-id，所以它自然可以算出要通知哪个acker来ack。

4. 当所有子tuple都被ack之后，val会被异或成0，OK 整个tuple树执行跟踪完成。

场景分析：

1. 由于对应的task挂掉了，一个tuple没有被ack： storm的超时机制在超时之后会把这个tuple标记为失败，从而可以重新处理。

2. Acker挂掉了：这种情况下由这个acker所跟踪的所有spout tuple都会超时，也就会被重新处理。

3. Spout挂掉了：在这种情况下给spout发送消息的消息源负责重新发送这些消息。比如Kestrel和RabbitMQ在一个客户端断开之后会把所有”处理中“的消息放回队列。
由此可见storm的高度容错性。