strom ack 机制二

首先开启storm tracker机制的前提是，
1. 在spout emit tuple的时候，要加上第3个参数messageid 
2. 在配置中acker数目至少为1 
3. 在bolt emit的时候，要加上第二个参数anchor tuple，以保持tracker链路流程

1. 当tuple具有messageid时，spout会把该tuple加到pending list里面 
   并发消息给acker，通知acker开始tracker这条tuple
2. 然后再后续的bolt的处理逻辑中，你必须显式的ack或fail所有处理的tuple 
   如果这条tuple在整个DAG图上都成功执行了，那么acker会发现该tuple的track异或值为0 
   于是acker会发ack_message给spout 
   当然如果在DAG图上任意一个节点bolt上fail，那么acker会认为该tuple fail 
   于是acker会发fail_message给spout
3. 当spout收到ack或fail message如何处理， 
    首先是从pending list里面删掉这条tuple，因为无论ack或fail，只要得到结果，这条tuple就没有继续被cache的必要了 
    然后做的事是调用spout.ack或spout.fail 
    所以系统默认是不会做任何事的，甚至是fail后的重发，你也需要在fail里面自己实现 
    如何实现后面看
4. 如果一条tuple没有被ack或fail，最终是会超时的 
    Spout会根据system tick去rotate pending list，对于每个过时的tuple，都调用spout.fail

下面的问题就是如何做fail重发，
这个必须用户通过自己处理fail来做，系统是不会自己做的，
public void fail(Object msgId)
看看系统提供的接口，只有msgId这个参数，这里的设计不合理，其实在系统里是有cache整个msg的，只给用户一个messageid，用户如何取得原来的msg
貌似需要自己cache，然后用这个msgId去查询，太坑爹了
阿里自己的Jstorm会提供
public interface IFailValueSpout { void fail(Object msgId, List<object>values); }

这样更合理一些, 可以直接取得系统cache的msg values

5.在阿里的在 loghub spout 中，强制依赖 storm 的 ack 机制（做了messageid处理），用于确认 spout 将消息正确发送至 bolt，所以在 bolt 中一定要调用 ack 进行确认

6.spout中的ack是告诉具有事务功能的数据源该消息被成功处理。而bolt中的ack是告诉上一层组件该消息被成功处理