storm（08） storm訊息不丟失機制

通過ack機制，spout傳送出去的每一條訊息，都可以確定是被成功處理或失敗處理，從而可以讓開發者採取動作。比如在meta中，成功被處理，即可更新偏移量，當失敗時，重**送資料。

因此，通過ack機制，很容易做到保證所有資料均被處理，保證訊息不丟失。

另外需要注意的，當spout觸發fail動作時，不會自動重發失敗的tuple，需要spout自己重新獲取資料，手動重新再傳送一次。

ack機制即， spout傳送的每一條訊息：

在規定的時間內，spout收到acker的ack響應，即認為該tuple 被後續bolt成功處理

在規定的時間內，沒有收到acker的ack響應tuple，就觸發fail動作，即認為該tuple處理失敗，

或者收到acker傳送的fail響應tuple，也認為失敗，觸發fail動作

另外ack機制還常用於限流作用：為了避免spout傳送資料太快，而bolt處理太慢，常常設定pending數，當spout有等於或超過pending數的tuple沒有收到ack或fail響應時，跳過執行nexttuple，從而限制spout傳送資料。

通過conf.put(config.topology_max_spout_pending, pending);設定spout pend數。

timeout時間可以通過config.topology_message_timeout_secs來設定。timeout的預設時長為30秒

spout 在傳送資料的時候帶上msgid

設定acker數至少大於0；config.setnumackers(conf, ackerparal);

在bolt中完成處理tuple時，執行outputcollector.ack(tuple), 當失敗處理時，執行outputcollector.fail(tuple);

推薦使用ibasicbolt，因為ibasicbolt 自動封裝了outputcollector.ack(tuple), 處理失敗時，丟擲failedexception，則自動執行outputcollector.fail(tuple)

spout傳送資料是不帶上msgid 或者設定acker數等於0

storm 系統中有一組叫做"acker"的特殊的任務，它們負責跟蹤dag（有向無環圖）中的每個訊息。

acker任務儲存了spout id到一對值的對映。第乙個值就是spout的任務id，通過這個id，acker就知道訊息處理完成時該通知哪個spout任務。第二個值是乙個64bit的數字，我們稱之為"ack val"，它是樹中所有訊息的隨機id的異或計算結果。

ack val表示了整棵樹的的狀態，無論這棵樹多大，只需要這個固定大小的數字就可以跟蹤整棵樹。當訊息被建立和被應答的時候都會有相同的訊息id傳送過來做異或。每當acker發現一棵樹的ack val值為0的時候，它就知道這棵樹已經被完全處理了

ibasicbolt，basebasicbolt不用每次execute完成都寫ack/fail，因為底層已經實現好了。