之前對這個的理解有些問題，今天用到有仔細梳理了一遍，記錄一下
首先開啟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來做，系統是不會自己做的，
publicvoid fail(object msgid)
看看系統提供的介面，只有msgid這個引數，這裡的設計不合理，其實在系統裡是有cache整個msg的，只給使用者乙個messageid，使用者如何取得原來的msg
貌似需要自己cache，然後用這個msgid去查詢，太坑爹了
阿里自己的jstorm會提供
publicinte***ce ifailvaluespout
這樣更合理一些, 可以直接取得系統cache的msg values
Storm ack和fail機制再論
之前對這個的理解有些問題，今天用到有仔細梳理了一遍，記錄一下 首先開啟storm tracker機制的前提是，1.在spout emit tuple的時候，要加上第3個引數messageid 2.在配置中acker數目至少為1 3.在bolt emit的時候，要加上第二個引數anchor tuple...
Storm ack和fail機制再論
之前對這個的理解有些問題，今天用到有仔細梳理了一遍，記錄一下 首先開啟storm tracker機制的前提是，1.在spout emit tuple的時候，要加上第3個引數messageid 2.在配置中acker數目至少為1 3.在bolt emit的時候，要加上第二個引數anchor tuple...
通知機制和KVO機制
在cocoa touch框架中，觀察者模式的具體應用有兩個，即通知機制和kvo key value observing 模式機制。通知機制 通知機制與委託機制不同的是，通知是一對多的物件之間的通訊，而委託則是一對一物件之間的通訊。歸納一下通知主要有廣播通知 broadcast notificatio...