07消息重複發送問題與業務接口的冪等性設計

消息消費流程的異常點

消息的消費確認流程中，
任何一個環節均可能會出問題！

消息消費流程的異常處理

方法：對於未確認的消息，採用按規則從新投遞的方式進行處理。
問題：消息的重複發送會致使業務處理接口出現重複調用的問題。

消息重複發送的緣由

一、被動方應用接收到消息，業務處理完成後應用出問題，消息中間件不知道消息處理結果，會從新投遞消息。

二、被動方應用接收到消息，業務處理完成後網絡出問題，消息中間件收不到消息處理結果，會從新投遞消息。

三、被動方應用接收到消息，業務處理時間過長，消息中間件因消息超時未確認，會再次投遞消息。

四、被動方應用接收到消息，業務處理完成，消息中間件問題致使收不到消息處理結果，消息會從新投遞。

五、被動方應用接收到消息，業務處理完成，消息中間件收到了消息處理結果，但因爲消息存儲故障致使消息沒能成功確認，消息會再次投遞。

總結： 消息消費過程當中產生消息重複發送主要是由於消息接收者成功處理完消息後，消息中間件沒能及時更新消息投遞狀態（也就是消息沒能及時ACK確認）致使的。

容許消息重複發送的約束條件

約束：被動方應用對於消息的業務處理要實現冪等。

業務接口的冪等性設計

對於存在同一請求數據會發生重複調用的業務接口，接口的業務邏輯要實現冪等性設計。

在實際的業務應用場景中，業務接口的冪等性設計，常結合可查詢操做一塊兒使用。

場景舉例
•支付訂單建立：商戶編號+ 商戶訂單號+ 訂單狀態
•訂單更新處理：平臺訂單號+ 訂單狀態
•會計系統記帳：系統來源+ 請求號

 

消息重複發送限制

極端狀況：消息重發也得有次數限制，要否則就變成了死循環。
對於超太重發次限制的消息，進入DLQ，等待人工干預或延後按期處理。

消息的ACK確認