理解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：这条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的高度容错性。
原文链接：http://blog.itpub.net/29754888/viewspace-1261363/
