Storm ack和fail機制再論

標籤：style   class   blog   code   color   問題   

之前對這個的理解有些問題，今天用到有仔細梳理了一遍，記錄一下

 

首先開啟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