Storm的Acker機制是什么

這篇文章主要講解了“Storm的Acker機制是什么”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“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機制是什么這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！