这篇文章主要介绍“Storm的ack机制是什么”，在日常操作中，相信很多人在Storm的ack机制是什么问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”Storm的ack机制是什么”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！
创新互联建站-专业网站定制、快速模板网站建设、高性价比东丽网站开发、企业建站全套包干低至880元,成熟完善的模板库,直接使用。一站式东丽网站制作公司更省心,省钱,快速模板网站建设找我们，业务覆盖东丽地区。费用合理售后完善，10余年实体公司更值得信赖。
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。
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树里面， 也就不会被跟踪了。
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则认为已完全处理。
到此，关于“Storm的ack机制是什么”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注创新互联网站，小编会继续努力为大家带来更多实用的文章！
