共计 1613 个字符，预计需要花费 5 分钟才能阅读完成。
这篇文章主要讲解了“Storm 的 Acker 机制是什么”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着丸趣 TV 小编的思路慢慢深入，一起来研究和学习“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 机制是什么这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是丸趣 TV，丸趣 TV 小编将为大家推送更多相关知识点的文章，欢迎关注！
