消息不丢失機制ack
ack是什麼
ack 機制是storm整個技術體系中非常閃亮的一個創新點。
通過Ack機制，spout發送出去的每一條消息，都可以确定是被成功處理或失敗處理， 進而可以讓開發者采取動作。
比如在Meta中，成功被處理，即可更新偏移量，當失敗時，重複發送資料。
是以，通過Ack機制，很容易做到保證所有資料均被處理，一條都不漏。
另外需要注意的，當spout觸發fail動作時，不會自動重發失敗的tuple，需要spout自己重新擷取資料，手動重新再發送一次
ack機制即， spout發送的每一條消息，
l 在規定的時間内，spout收到Acker的ack響應，即認為該tuple 被後續bolt成功處理
l 在規定的時間内，沒有收到Acker的ack響應tuple，就觸發fail動作，即認為該tuple處理失敗，
l 或者收到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)
有2種途徑
spout發送資料是不帶上msgid
設定acker數等于0
Storm 系統中有一組叫做"acker"的特殊的任務，它們負責跟蹤DAG（有向無環圖）中的每個消息。
acker任務儲存了spout id到一對值的映射。第一個值就是spout的任務id，通過這個id，acker就知道消息處理完成時該通知哪個spout任務。第二個值是一個64bit的數字，我們稱之為"ack val"， 它是樹中所有消息的随機id的異或計算結果。
<TaskId,<RootId,ackValue>>
Spoutid,<系統生成的id,ackValue>
Task-0,64bit,0
ack val表示了整棵樹的的狀态，無論這棵樹多大，隻需要這個固定大小的數字就可以跟蹤整棵樹。當消息被建立和被應答的時候都會有相同的消息id發送過來做異或。 每當acker發現一棵樹的ack val值為0的時候，它就知道這棵樹已經被完全處理了
對于spout，有ISpout，IRichSpout，BaseRichSpout
對于bolt，有IBolt，IRichBolt，BaseRichBolt，IBasicBolt，BaseBasicBolt
IBasicBolt，BaseBasicBolt不用每次execute完成都寫ack/fail，因為已經幫你實作好了。
坑在哪裡？
1、BaseBasicBolt
ack方法有回調
2、BaseRichBolt
ack方法沒有回調