ApsaraMQ for RocketMQ：消費重試

訊息重試的觸發條件

• 消費失敗，包括消費者返回訊息失敗狀態標識或拋出非預期異常。

• 訊息處理逾時，包括在PushConsumer中排隊逾時。

訊息重試主要行為

• 重試過程狀態機器：控制訊息在重試流程中的狀態和變化邏輯。

• 稍候再試：上一次消費失敗或逾時後，距下次訊息可被重新消費的間隔時間。

• 最大重試次數：訊息可被重試消費的最大次數。

訊息重試策略差異

具體的重試策略，請參見下文PushConsumer消費重試策略和SimpleConsumer消費重試策略。

重試狀態機器

舉例：某條訊息的消費重試流程如上圖所示，假設訊息處於已就緒狀態的時間長度為5 s，消費耗時為6 s。

每次重試訊息狀態都會經過已就緒->處理中->待重試的變化，訊息的稍候再試指的是上一次消費失敗或逾時後，距下次訊息可被重新消費的間隔時間。實際訊息兩次消費之間的間隔時間還包括消費耗時和已就緒狀態的期間。例如：

• 訊息第一次消費時第0 s進入已就緒狀態。

• 受消費者處理速度的影響，到第5 s時才開始拉取訊息消費，6 s後訊息處理異常用戶端返回消費失敗。

• 此時還不能進行消費重試，需要等待稍候再試後才能開始再次消費。

• 等到第21 s時訊息再次變為已就緒狀態。

• 5 s後用戶端才再次開始重新消費訊息。

因此，實際訊息兩次消費的間隔時間為：消費耗時+稍候再試+已就緒的期間=21 s。

稍候再試時間

• 無序訊息（非順序訊息）：稍候再試為階梯時間，具體時間如下：

  第幾次重試	稍候再試時間	第幾次重試	稍候再試時間
  1	10秒	9	7分鐘
  2	30秒	10	8分鐘
  3	1分鐘	11	9分鐘
  4	2分鐘	12	10分鐘
  5	3分鐘	13	20分鐘
  6	4分鐘	14	30分鐘
  7	5分鐘	15	1小時
  8	6分鐘	16	2小時

  說明

  若重試次數超過16次，後面每次稍候再試都為2小時。

• 順序訊息：稍候再試為固定時間，具體取值，請參見參數限制。

最大重試次數

• 預設值：16次。

• 最大限制：不超過1000次。

PushConsumer的最大重試次數由消費者分組的中繼資料控制，修改方式，請參見修改最大重試次數。

例如，最大重試次數為3次，則該訊息最多可被投遞4次，1次為原始訊息，3次為重試投遞次數。

使用樣本

PushConsumer觸發訊息重試只需要返回消費失敗的狀態代碼即可，當出現非預期的異常時，也會被SDK捕獲。

SimpleConsumer simpleConsumer = null;
        //消費樣本：使用PushConsumer消費普通訊息，如果消費失敗返回錯誤，即可觸發重試。
        MessageListener messageListener = new MessageListener() {
            @Override
            public ConsumeResult consume(MessageView messageView) {
                System.out.println(messageView);
                //返回消費失敗，會自動重試，直至到達最大重試次數。
                return ConsumeResult.FAILURE;
            }
        };
            

查看消費重試日誌

PushConsumer順序消費的重試是在消費者用戶端進行，服務端無法擷取消費重試的詳細日誌，若訊息軌跡中順序訊息的投遞結果為失敗時，您需要在消費者用戶端日誌中查看訊息重試的最大次數、消費者用戶端等資訊。

消費者用戶端日誌查看路徑，請參見日誌配置。

您可以通過搜尋以下關鍵字在用戶端日誌中快速定位消費失敗的相關內容：

Message listener raised an exception while consuming messages
Failed to consume fifo message finally, run out of attempt times

重試狀態機器

和PushConsumer消費重試策略不同的是，SimpleConsumer消費者的稍候再試是預分配的，每次擷取訊息，消費者會在調用API時設定一個不可見時間參數InvisibleDuration，即訊息的最大處理時間長度。若訊息消費失敗觸發重試，不需要設定下一次重試的時間間隔，直接複用不可見時間參數的取值。

由於不可見時間為預分配的，可能和實際業務中的訊息處理時間差別較大，您可以通過API介面修改不可見時間。

例如，您預設訊息處理耗時最多20 ms，但實際業務中20 ms內訊息處理不完，您可以修改訊息不可見時間，延長訊息處理時間，避免訊息觸發重試機制。

如下圖所示，訊息不可見時間修改後立即生效，即從調用API時刻開始，重新計算訊息不可見時間。

訊息稍候再試

訊息稍候再試=不可見時間－訊息實際處理時間長度

SimpleConsumer的消費稍候再試通過訊息的不可見時間控制。例如，訊息不可見時間為30 ms，實際訊息處理用了10 ms就返回失敗響應，則距下次訊息重試還需要20 ms，此時的訊息稍候再試即為20 ms；若直到30 ms訊息還未處理完成且未返回結果，則訊息逾時，立即重試，此時稍候再試即為0 ms。

最大重試次數

• 預設值：16次。

• 最大限制：不超過1000次。

SimpleConsumer的最大重試次數由消費者分組建立的中繼資料控制，修改方式，請參見修改最大重試次數。

例如，最大重試次數為3次，則該訊息最多可被投遞4次，1次為原始訊息，3次為重試投遞次數。

使用樣本

SimpleConsumer觸發訊息重試只需要等待即可。

 //消費樣本：使用SimpleConsumer消費普通訊息，如果希望重試，只需要靜默等待逾時即可，服務端會自動重試。
        List<MessageView> messageViewList = null;
        try {
            messageViewList = simpleConsumer.receive(10, Duration.ofSeconds(30));
            messageViewList.forEach(messageView -> {
                System.out.println(messageView);
                //如果處理失敗，希望服務端重試，只需要忽略即可，等待訊息再次可見後即可重試擷取。
            });
        } catch (ClientException e) {
            //如果遇到系統流控等原因造成拉取失敗，需要重新發起擷取訊息請求。
            e.printStackTrace();
        }

gRPC SDK

• 通過OpenAPI方式修改：更新消費者分組

• 通過控制台方式修改：

  操作入口如下：

  1. 在執行個體列表頁面中單擊目標執行個體名稱。

  2. 在左側導覽列單擊Group 管理，然後在Group 管理頁面單擊创建 Group。

  

Remoting SDK

• 通過 Remoting SDK 參數修改：修改consumer的 maxReconsumeTimes 屬性值。

合理重試，避免因限流等訴求觸發消費重試

上文應用情境中提到，訊息重試適用業務處理失敗且當前消費為小機率事件的情境，不適合在連續性失敗的情境下使用，例如消費限流情境。

• 錯誤樣本：

  如果當前消費速度過高觸發限流，則返回消費失敗，等待下次重新消費。

• 正確樣本：

  如果當前消費速度過高觸發限流，則延遲擷取訊息，稍後再消費。

訊息消費逾時時間如何設定？

消費逾時時間由消費者用戶端設定，具體參數設定如下：

consumer.setConsumeTimeout(15); //參數單位：分鐘，最小1分鐘，最大180分鐘