Storm采用对元组中携带的Spout元组message-id哈希取模的方法来把一个元组映射到一个acker任务上(所以同一个消息树里的所有消息都会映射到同一个acker任务)。因为每个元组携带了自己所处的元组树中根节点Spout元组(可能有多个)的标识，所以Storm就能决定通知哪个acker任务。

?

当一个Spout任务产出一个新的元组，仅需要简单的发送一个消息给对应的acker(Spout元组message-id哈希取模)来告知Spout的任务标示(task id)，以此来通知acker当前这个Spout任务负责这个消息。当acker看到一个消息树被完全处理完，它就能根据处理的元组中携带的Spout元组message-id来确定产生这个Spout元组的task id，然后通知这个Spout任务消息树处理完成(调用 Spout任务的ack函数)。

?

实现细节

?

对于拥有上万节点（或者更多）的巨大的元组树，跟踪所有的元组树会耗尽acker使用的内存。acker任务不显示地(记录完整的树型结构)跟踪元组树，相反它使用了一种每个Spout元组只占用固定大小空间（大约20字节）的策略。这个跟踪算法是Storm工作的关键，而且是重大突破之一。

?

一个acker任务存储了从一个Spout元组message-id到一对值的映射关系spout-message-id-->。第一个值是创建了这个Spout元组的任务id，用来后续处理完成时通知到这个Spout任务。第二个值是一个64比特的叫做“ack val”的数值。它是简单的把消息树中所有被创建或者被确认的元组message-id异或起来的值。每个消息创建和被确认处理后都会异或到"ack val"上，A xor A = 0，所以当一个“ack val”变成了0，说明整个元组树都完全被处理了。无论是很大的还是很小的元组树，"ack val"值都代表了整个元组树中消息的处理状态。由于元组message-id是随机的64比特的整数，所以同一个元组树中不同元组message-id发生撞车的可能性特别小，因此“ack val”意外的变成0的可能性非常小。如果真的发生了这种情况，而恰好这个元组也处理失败了，那仅仅会导致这个元组的数据丢失。

?

使用异或操作来跟踪消息树处理状态的想法非常有才。因为消息的数量可能有成千上万条，每个都单独跟踪(读者可以思考下怎么搞)是非常低效而且不可水平扩展的。而且采用异或的方式后，就不依赖于acker接收到消息的顺序了。

?

搞明白了可靠性的算法，让我们看看所有失败的场景下Storm如何避免数据丢失：

?

Bolt任务挂掉：导致一个元组没有被确认，这种场景下，这个元组所在的消息树中的根节点Spout元组会超时并被重新处理

acker任务挂掉：这种场景下，这个acker挂掉时正在跟踪的所有的Spout元组都会超时并被重新处理

Spout任务挂掉：这种场景下，需要应用自己实现检查点机制，记录当前Spout成功处理的进度，当Spout任务挂掉之后重启时，继续从当前检查点处理，这样就能重新处理失败的那些元组了。

调整可靠性

?

acker任务是轻量级的，所以在一个拓扑中不需要太多的acker任务。可以通过Storm UI(id为"__acker"的 组件）来观察acker任务的性能。如果吞吐量看起来不正常，就需要添加更多的acker任务。

?

去掉可靠性

?

如果可靠性无关紧要－－例如你不关心元组失败场景下的消息丢失－－那么你可以通过不跟踪元组的处理过程来提高性能。不跟踪一个元组树会让传递的消息数量减半，因为正常情况下，元组树中的每个元组都会有一个确认消息。另外，这也能减少每个元组需要存储的id的数量(指每个元组存储的Spout message-id)，减少了带宽的使用。

?

有三种方法来去掉可靠性：

?

设置Config.TOPOLOGY_ACKERS为0。这种情况下，Storm会在Spout吐出一个元组后立马调用Spout的ack函数。这个元组树不会被跟踪。

当产生一个新元组调用emit函数的时候通过忽略消息message-id参数来关闭这个元组的跟踪机制。

如果你不关心某一类特定的元组处理失败的情况，可以在调用emit的时候不要使用锚定。由于它们没有被锚定到某个Spout元组上，所以当它们没有被成功处理，不会导致Spout元组处理失败。