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