java基礎總結(八十七)--Ack機制

轉載的第一篇部落格

原文連結

1、ack是什麼

ack 機制是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數。.

2、如何使用Ack機制

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)

3、如何關閉Ack機制

有2種途徑

spout發送資料時不帶上msgid

設定acker數等于0

4、基本實作

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

<TaskId,<RootId,ackValue>>

Spoutid,<系統生成的id,ackValue>

Task-0,64bit,0

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

STORM的消息容錯機制

資料在進行中出現異常時，需要保證消息被完整處理。

SPOUT --A---B---C---D

期望:當其中一個環節出現異常時，Spout能夠重新發送一份資料。

問題:SPOUT如何知道一條消息的處理狀态

成功:ack(Object msgid)

失敗:fail(Object msgid)

:Bolt如何告知Spout消息處理的狀态

collector.emit(new Value())

collector.ack() //當消息處理成功時

collector.fail()//當消息處理失敗時

Ack機制

Spout發送一條資料出去，需要知道資料處理成功和失敗的狀态，如果失敗進行消息的重新發送

1、自定義spout實作BaseRichSpout，覆寫ack，fail方法。

2、在自定義的spout發送資料的時候，需要制定messageid，messageid是一個Object。

3、當消息處理成功或失敗之後，Storm架構會将messageId傳回來。

如果消息要重發，直接通過messageId找到或直接轉化成資料内容進行重發。

4、自定義Bolt實作BaseRichBolt

5、在bolt的execute中進行兩個操作

5.1、發送資料時，需要指定血緣關系，錨點

collector.emit(父tuple，new 子Tuple)

5.2、當execute處理完業務邏輯的時候，需要告訴storm架構目前階段的處理狀态。

collector.ack(tuple)

如果在編寫storm程式時，在bolt環節忘了手動ack或fail，怎麼辦？

忘了手動ack或fail，storm架構會等待回報，達到逾時門檻值之後，就直接給fail。

如果在編寫storm程式時，在bolt環節忘了辨別錨點，怎麼辦？

忘了辨別錨點，就是忘了辨別血緣關系。storm會認為你不關心後面階段的處理狀況。

Storm BaseRichBolt API 過于繁瑣，就開了另外一個api：BaseBasicBolt

如果實作了BaseBasicBolt，就不需要錨點，不需要手動ack或fail。

轉載的第二篇部落格

原文連結

由于通信過程的不可靠性，傳輸的資料不可避免的會出現丢失、延遲、錯誤、重複等各種狀況，TCP協定為解決這些問題設計了一系列機制。這個機制的核心，就是發送方向接收方發送資料後，接收方要向發送方發送ACK（回執）。如果發送方沒接收到正确的ACK，就會重新發送資料直到接收到ACK為止。比如：發送方發送的資料序号是seq，那麼接收方會發送seq + 1作為ACK，這樣發送方就知道接下來要發送序号為seq + 1的資料給接收方了。

• 資料丢失或延遲。發送方發送資料seq時會起一個定時器，如果在指定時間内沒有接收到ACK seq + 1，就把資料seq再發一次。
• 資料亂序。接收方上一個收到的正确資料是seq + 4，它傳回seq + 5作為ACK。這時候它收到了seq + 7，因為順序錯了，是以接收方會再次傳回seq + 5給發送方。
• 資料錯誤。每一個TCP資料都會帶着資料的校驗和。接收方收到資料seq + 3以後會先對校驗和進行驗證。如果結果不對，則發送ACK seq + 3，讓發送方重新發送資料。
• 資料重複。接收方直接丢棄重複的資料即可。