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机制是什么这一问题有了更深刻的体会,具体使用情况还需要大家实践验证。这里是恰卡编程网,小编将为大家推送更多相关知识点的文章,欢迎关注!