Storm的Acker机制是什么

这篇文章主要讲解了“Storm的Acker机制是什么”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“Storm的Acker机制是什么”吧！

基本概念的解析

对于Storm，有一个相对比较重要的概念就是 "Guarantee no data loss" -- 可靠性

很明显,要做到这个特性，必须要tracker 每一个data的去向和结果，Storm是如何做到的

-》 那就是我们接下来要说的 Acker 机制，先概括下Acker所参与的工作流程

1 Spout 创建一个新的Tuple时候，会发射一个消息通知acker去跟踪；

2 Bolt 在处理Tuple成功或者失败的时候，也会发送一个消息通知Acker

3 Acker会好到发射该Tuple的Spout，回掉其Ack ，fail方法

一个tuple被完全处理的意思是：

这个tuple以及由这个tuple后续所导致的所有tuple 都被成功的处理， 而一个tuple会被认为处理失败了，如果这个

消息在timeout所指定的时间内没有成功处理

也就是说对于任何一个Spout-tuple以及它的子孙，到底处理成功失败与否，我们都会得到通知

由一个tuple产生一个新的tuple称为：anchoring，你发射一个tuple的同时也就完成了一次anchoring

Storm 里面有一类特殊的task称为：acker，请注意，Acker也是属于一种task，如果您对Task还不够熟悉，请参考另外的一篇文档：有关Storm-executor-task的关系，acker负责跟踪spout发出的每一个tuple的tuple树，当Acker发现一个tuple树已经处理完成了，它就会发送一个消息给产生这个tuple的task。

Acker task 组件来设置一个topology里面的acker的数量，默认值是一，如果你的topoogy里面的tuple比较多的话，那么请把acker的数量设置多一点，效率会更高一点。

理解Storm的可靠性的办法是看看 tuple，tuple树的生命周期，当一个tuple被创建，不管是Spout 和bolt 创建的，他被赋予一个位的ID，而acker就是利用这个ID 去跟踪所有的tuple的。每一个tuple知他祖宗的iD，吐过Stomr检测到一个tuple被完全处理了，那么Storm会以最开始的那个message-id 作为参数去调用消息源头的ACk方法，反之Storm会调用Spout的fail方法，

值得注意的一点是Storm调用Ack或则fail的task始终是产生这个tuple的那个task，所以如果一个Spout，被分为很多个task来执行，消息执行的成功失败与否始终会通知最开始发出tuple的那个task

Storm的可靠性产景

作为Storm的使用者，有两件事情要做以更好的利用Storm的可靠性特征，首先你在生成一个tuple的时候要通知Storm，其次，完全处理一个tuple之后要通知Storm，这样Storm就可以检测到整个tuple树有没有完成处理，并且通知源Spout处理结果

1  由于对应的task挂掉了，一个tuple没有被Ack：

    Storm的超时机制在超时之后会把这个tuple标记为失败，从而可以重新处理

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

3 Spout 挂掉了：在这种情况下给Spout发送消息的消息源负责重新发送这些消息

三个基本的机制，保证了Storm的完全分布式，可伸缩的并且高度容错的。

感谢各位的阅读，以上就是“Storm的Acker机制是什么”的内容了，经过本文的学习后，相信大家对Storm的Acker机制是什么这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是亿速云，小编将为大家推送更多相关知识点的文章，欢迎关注！