Strom学习00---ack机制

Storm的ack机制

ack/fail消息确认机制

首先可以看下SpoutOutputCollector的解释： 与OutputCollector的区别
This output collector exposes the API for emitting tuples from an backtype.storm.topology.IRichSpout. 
The main difference between this output collector and OutputCollector for
backtype.storm.topology.IRichBolt is that spouts can tag messages with ids so that 
they can be acked or failed later on. This is the Spout portion of Storm's API to guarantee 
that each message is fully processed at least once.

1、Tuple树

  在Storm的一个topoplogy中，Spout通过SpoutOutputCollector的emit()发射一个tuple（源）即消息，然后经过topology定义的多个Bolt处理时，就会产生一个或者多个新的Tuple，源Tuple和新的Tuple构成一个Tuple树。
当整棵树处理完了，才算一个Tuple完全处理。
其中任何一个节点的Tuple处理失败或者超时，则整颗树失败，如下图Tuple tree.

2、超时

关于消息在storm中超时默认为30秒，具体参数看defaults.yaml中的
topology.message.timeout.secs:30的配置.
同时可以在定义Topology时，通过conf.setMessageTimeoutSecs()指定超时的时间。

3、消息可靠性

Storm所谓的消息可靠性指的是storm保证每个tuple被topology完全处理。
出现失败的原因可能为：

• 节点处理失败
• 节点处理超时

4、自动ack和手动ack

Strom中有BasicBolt和RichBolt, 两者的ack方式不同

• BasicBolt 自动ack
  
  • BasicOutputCollector在emit数据的时候，会自动和输入的tuple相关联，
  • 在execute方法结束的时候，输入的tuple会自动的ack(有一定的条件)
• RichBolt 手动ack
  
  • 在emit数据的时候，显示指定该数据的源tuple,
    
    • 即：collector.emit(oldTuple, newTuple);
  • 并且需要在execute（）执行成功后，调用源Tuple的ack进行ack。

5、去掉可靠性

如果可靠性要求不高，在一些失败的情况下损失一些数据，可以忍受，那么可以通过不跟踪这些tuple树来提高性能。
有三种方法去掉可靠性:

• 1、把Config.TOPOLOGY_ACKERS 设置成 0. 在这种情况下， storm会在 spout发射一个tuple之后马上调用spout的ack方法。也就是说这个tuple树不 会被跟踪。
• 2、在tuple层面去掉可靠性。 你可以在发射tuple的时候不指定 messageid来达到不跟踪某个特定的spout tuple的目的。
• 3、如果你对于一个tuple树里面的某一部分到底成不成功不是很 关心，那么可以在发射这些tuple的时候unanchor它们。 这样这些tuple就不 在tuple树里面， 也就不会被跟踪。

6、Ack原理

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则认为已完全处理

二 、问题重现， ack解决

2.1、生产者只发一次1，2，3

2.2、storm重复消费

？？？？

没有调用确认机制（ack ro fail）