Ack机制

Storm可以保证从Spout发出的每个数据都被完全处理，从Spout发出的数据可能会产生成千上万的数据。 一个Tuple被完全处理指：这个Tuple以及这个Tuple产生的所有Tuple都被成功处理。而一个Tuple被认为处理失败是被是指在timeout时间内没有被成功处理（包括显示的fail和超时导致的失败）。 这个timeout时间可以通过 Config.TOPOLOGY_MESSAGE_TIMEOUT_SECS来设定。Timeout的默认时长为30秒。

Storm的Bolt有BsicBolt和RichBolt，在BasicBolt中，BasicOutputCollector在emit数据的时候，会自动和输入的tuple相关联，而在execute方法结束的时候那个输入tuple会被自动ack。

在使用RichBolt时要实现ack，则需要在emit数据的时候，显示指定该数据的源tuple，即collector.emit(oldTuple, newTuple);并且需要在execute执行成功后调用源tuple的ack进行ack。

需要说明的是，要实现ack机制，必须在spout发射tuple的时候指定messageId。并且需要在spout中对tuple进行缓存，对于ack的tuple则从缓存队列中删除，对于fail的tuple可以选择重发。不同的Tuple可以绑定同一个messageId，表明这多个Tuple对用户来说是同一个消息单元。

这个messageId只是业务上为了我们方便区分是哪个Tuple返回来的，Storm内部并不对其进行处理。因此，不同的Tuple绑定同一个messageId时，在ack和fail中不能区分是哪个Tuple成功或失败，只知道其绑定的messageId。

调整可靠性 (Tuning Reliability)

Acker task是非常轻量级的， 所以一个topology里面不需要很多acker。你可以通过Strom UI(id: -1)来跟踪它的性能。 如果它的吞吐量看起来不正常，那么你就需要多加点acker了。

如果可靠性对你来说不是那么重要 — 你不太在意在一些失败的情况下损失一些数据， 那么你可以通过不跟踪这些tuple树来获取更好的性能。不去跟踪消息的话会使得系统里面的消息数量减少一半， 因为对于每一个tuple都要发送一个ack消息。并且它需要更少的id来保存下游的tuple， 减少带宽占用。

有三种方法可以去掉可靠性。第一是把Config.TOPOLOGY_ACKERS 设置成 0. 在这种情况下， storm会在spout发射一个tuple之后马上调用spout的ack方法。也就是说这个tuple树不会被跟踪。

第二个方法是在tuple层面去掉可靠性。 你可以在发射tuple的时候不指定messageid来达到不跟粽某个特定的spout tuple的目的。

最后一个方法是如果你对于一个tuple树里面的某一部分到底成不成功不是很关心，那么可以在发射这些tuple的时候unanchor它们。 这样这些tuple就不在tuple树里面， 也就不会被跟踪了。

Ack原理

Storm中有个特殊的task，他们负责跟踪spout发出的每一个Tuple的Tuple树。当acker发现一个Tuple树已经处理完成了，它会发送一个消息给产生这个Tuple的那个task。Acker的跟踪算法是Storm的主要突破之一，对任意大的一个Tuple树，它只需要恒定的20字节就可以进行跟踪。

Acker跟踪算法的原理：acker对于每个spout-tuple保存一个ack-val的校验值，它的初始值是0，然后每发射一个Tuple或Ack一个Tuple时，这个Tuple的id就要跟这个校验值异或一下，并且把得到的值更新为ack-val的新值。那么假设每个发射出去的Tuple都被ack了，那么最后ack-val的值就一定是0。Acker就根据ack-val是否为0来判断是否完全处理，如果为0则认为已完全处理。