之前對這個的理解有些問題，今天用到有仔細梳理了一遍，記錄一下
首先開啟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