共計 1613 個字符，預計需要花費 5 分鐘才能閱讀完成。

這篇文章主要講解了“Storm 的 Acker 機制是什么”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著丸趣 TV 小編的思路慢慢深入，一起來研究和學習“Storm 的 Acker 機制是什么”吧！

基本概念的解析

對于 Storm，有一個相對比較重要的概念就是 Guarantee no data loss — 可靠性

很明顯, 要做到這個特性，必須要 tracker 每一個 data 的去向和結果，Storm 是如何做到的

-》那就是我們接下來要說的 Acker 機制，先概括下 Acker 所參與的工作流程

1 Spout 創建一個新的 Tuple 時候，會發射一個消息通知 acker 去跟蹤；

2 Bolt 在處理 Tuple 成功或者失敗的時候，也會發送一個消息通知 Acker

3 Acker 會好到發射該 Tuple 的 Spout，回掉其 Ack，fail 方法

一個 tuple 被完全處理的意思是：

這個 tuple 以及由這個 tuple 后續所導致的所有 tuple 都被成功的處理，而一個 tuple 會被認為處理失敗了，如果這個

消息在 timeout 所指定的時間內沒有成功處理

也就是說對于任何一個 Spout-tuple 以及它的子孫，到底處理成功失敗與否，我們都會得到通知

由一個 tuple 產生一個新的 tuple 稱為：anchoring，你發射一個 tuple 的同時也就完成了一次 anchoring

Storm 里面有一類特殊的 task 稱為：acker，請注意，Acker 也是屬于一種 task，如果您對 Task 還不夠熟悉，請參考另外的一篇文檔：有關 Storm-executor-task 的關系，acker 負責跟蹤 spout 發出的每一個 tuple 的 tuple 樹，當 Acker 發現一個 tuple 樹已經處理完成了，它就會發送一個消息給產生這個 tuple 的 task。

Acker task 組件來設置一個 topology 里面的 acker 的數量，默認值是一，如果你的 topoogy 里面的 tuple 比較多的話，那么請把 acker 的數量設置多一點，效率會更高一點。

理解 Storm 的可靠性的辦法是看看 tuple，tuple 樹的生命周期，當一個 tuple 被創建，不管是 Spout 和 bolt 創建的，他被賦予一個位的 ID，而 acker 就是利用這個 ID 去跟蹤所有的 tuple 的。每一個 tuple 知他祖宗的 iD，吐過 Stomr 檢測到一個 tuple 被完全處理了，那么 Storm 會以最開始的那個 message-id 作為參數去調用消息源頭的 ACk 方法，反之 Storm 會調用 Spout 的 fail 方法，

值得注意的一點是 Storm 調用 Ack 或則 fail 的 task 始終是產生這個 tuple 的那個 task，所以如果一個 Spout，被分為很多個 task 來執行，消息執行的成功失敗與否始終會通知最開始發出 tuple 的那個 task

Storm 的可靠性產景

作為 Storm 的使用者，有兩件事情要做以更好的利用 Storm 的可靠性特征，首先你在生成一個 tuple 的時候要通知 Storm，其次，完全處理一個 tuple 之后要通知 Storm，這樣 Storm 就可以檢測到整個 tuple 樹有沒有完成處理，并且通知源 Spout 處理結果

1   由于對應的 task 掛掉了，一個 tuple 沒有被 Ack：

 Storm 的超時機制在超時之后會把這個 tuple 標記為失敗，從而可以重新處理

2 Acker 掛掉了：在這種情況下，由這個 Acker 所跟蹤的所有 spout tuple 都會出現超時，也會被重新的處理

3 Spout 掛掉了：在這種情況下給 Spout 發送消息的消息源負責重新發送這些消息

三個基本的機制，保證了 Storm 的完全分布式，可伸縮的并且高度容錯的。

感謝各位的閱讀，以上就是“Storm 的 Acker 機制是什么”的內容了，經過本文的學習后，相信大家對 Storm 的 Acker 機制是什么這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是丸趣 TV，丸趣 TV 小編將為大家推送更多相關知識點的文章，歡迎關注！