Storm的ack機制是什么

這篇文章主要介紹“Storm的ack機制是什么”，在日常操作中，相信很多人在Storm的ack機制是什么問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Storm的ack機制是什么”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

Ack機制

Storm可以保證從Spout發出的每個數據都被完全處理，從Spout發出的數據可能會產生成千上萬的數據。 一個Tuple被完全處理指：這個Tuple以及這個Tuple產生的所有Tuple都被成功處理。而一個Tuple被認為處理失敗是被是指在timeout時間內沒有被成功處理（包括顯示的fail和超時導致的失敗）。 這個timeout時間可以通過 Config.TOPOLOGY_MESSAGE_TIMEOUT_SECS來設定。Timeout的默認時長為30秒。

Storm的Bolt有BsicBolt和RichBolt，在BasicBolt中，BasicOutputCollector在emit數據的時候，會自動和輸入的tuple相關聯，而在execute方法結束的時候那個輸入tuple會被自動ack。

在使用RichBolt時要實現ack，則需要在emit數據的時候，顯示指定該數據的源tuple，即collector.emit(oldTuple, newTuple);并且需要在execute執行成功后調用源tuple的ack進行ack。

需要說明的是，要實現ack機制，必須在spout發射tuple的時候指定messageId。并且需要在spout中對tuple進行緩存，對于ack的tuple則從緩存隊列中刪除，對于fail的tuple可以選擇重發。不同的Tuple可以綁定同一個messageId，表明這多個Tuple對用戶來說是同一個消息單元。

這個messageId只是業務上為了我們方便區分是哪個Tuple返回來的，Storm內部并不對其進行處理。因此，不同的Tuple綁定同一個messageId時，在ack和fail中不能區分是哪個Tuple成功或失敗，只知道其綁定的messageId。

調整可靠性 (Tuning Reliability)

Acker task是非常輕量級的， 所以一個topology里面不需要很多acker。你可以通過Strom UI(id: -1)來跟蹤它的性能。 如果它的吞吐量看起來不正常，那么你就需要多加點acker了。

如果可靠性對你來說不是那么重要 — 你不太在意在一些失敗的情況下損失一些數據， 那么你可以通過不跟蹤這些tuple樹來獲取更好的性能。不去跟蹤消息的話會使得系統里面的消息數量減少一半， 因為對于每一個tuple都要發送一個ack消息。并且它需要更少的id來保存下游的tuple， 減少帶寬占用。

有三種方法可以去掉可靠性。第一是把Config.TOPOLOGY_ACKERS 設置成 0. 在這種情況下， storm會在spout發射一個tuple之后馬上調用spout的ack方法。也就是說這個tuple樹不會被跟蹤。

第二個方法是在tuple層面去掉可靠性。 你可以在發射tuple的時候不指定messageid來達到不跟粽某個特定的spout tuple的目的。

最后一個方法是如果你對于一個tuple樹里面的某一部分到底成不成功不是很關心，那么可以在發射這些tuple的時候unanchor它們。 這樣這些tuple就不在tuple樹里面， 也就不會被跟蹤了。

Ack原理

Storm中有個特殊的task，他們負責跟蹤spout發出的每一個Tuple的Tuple樹。當acker發現一個Tuple樹已經處理完成了，它會發送一個消息給產生這個Tuple的那個task。Acker的跟蹤算法是Storm的主要突破之一，對任意大的一個Tuple樹，它只需要恒定的20字節就可以進行跟蹤。

Acker跟蹤算法的原理：acker對于每個spout-tuple保存一個ack-val的校驗值，它的初始值是0，然后每發射一個Tuple或Ack一個Tuple時，這個Tuple的id就要跟這個校驗值異或一下，并且把得到的值更新為ack-val的新值。那么假設每個發射出去的Tuple都被ack了，那么最后ack-val的值就一定是0。Acker就根據ack-val是否為0來判斷是否完全處理，如果為0則認為已完全處理。

到此，關于“Storm的ack機制是什么”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！