*作者：斜陽*

## 引言

本文主要介紹在使用 RocketMQ 時為什麼需要**重試與兜底機制**，生產者與消費者觸發**重試的條件和具體行為**，如何在 RocketMQ 中**合理使用重試機制**，幫助構建彈性，高可用系統的**最佳實踐**。

RocketMQ 的重試機制包括三部分，分別是生產者重試，服務端內部資料複製遇到非預期問題時重試，消費者消費重試。本文中僅討論生產者重試和消費者消費重試兩種面向使用者側的實現。

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3165b3a45b354171bcd106d1a9b4e474~tplv-k3u1fbpfcp-zoom-1.image "1.png")

## 生產者傳送重試

RocketMQ 的生產者在傳送訊息到服務端時，可能會因為網路問題，服務異常等原因導致呼叫失敗，這時候應該怎麼辦？如何儘可能的保證訊息不丟失呢？

### 1. 生產者重試次數

RocketMQ 在客戶端中內建了請求重試邏輯，支援在初始化時配置訊息傳送**最大重試次數（預設為 2 次**），失敗時會按照設定的重試次數重新傳送。直到訊息傳送成功，或者達到最大重試次數時結束，並在最後一次失敗後返回撥用錯誤的響應。對於**同步傳送和非同步傳送，均支援訊息傳送重試**。

-   同步傳送：呼叫執行緒會一直阻塞，直到某次重試成功或最終重試失敗（返回錯誤碼或丟擲異常）。
-   非同步傳送：呼叫執行緒不會阻塞，但呼叫結果會透過回撥的形式，以異常事件或者成功事件返回。

### 2. 生產者重試間隔

在介紹生產者重試前，我們先來了解下流控的概念，流控一般是指服務端壓力過大，容量不足時服務端會限制客戶端收發訊息的行為，是服務端自我保護的一種設計。RocketMQ 會根據當前是否觸發了流控而採用不同的重試策略：

**非流控錯誤場景**：其他觸發條件觸發重試後，均會**立即進行重試，無等待間隔**。

**流控錯誤場景**：系統會按照預設的**指數退避策略進行延遲重試**。

-   **為什麼要引入退避和隨機抖動？**

如果故障是由過載流控引起的，**重試會增加服務端負載，導致情況進一步惡化**，因此客戶端在遇到流控時會在兩次嘗試之間等待一段時間。每次嘗試後的等待時間都呈指數級延長。指數回退可能導致很長的回退時間，因為指數函式增長很快。指數退避演算法透過以下引數控制重試行為，更多資訊，請參見 connection-backoff.md。

INITIAL_BACKOFF：第一次失敗重試前後需等待多久，預設值：1 秒；  
MULTIPLIER ：指數退避因子，即退避倍率，預設值：1.6；  
JITTER ：隨機抖動因子，預設值：0.2；  
MAX_BACKOFF ：等待間隔時間上限，預設值：120 秒；  
MIN_CONNECT_TIMEOUT ：最短重試間隔，預設值：20 秒。

```
ConnectWithBackoff()
  current_backoff = INITIAL_BACKOFF
  current_deadline = now() + INITIAL_BACKOFF
  while (TryConnect(Max(current_deadline, now() + MIN_CONNECT_TIMEOUT))!= SUCCESS)
    SleepUntil(current_deadline)
    current_backoff = Min(current_backoff * MULTIPLIER, MAX_BACKOFF)
    current_deadline = now() + current_backoff + UniformRandom(-JITTER * current_backoff, JITTER * current_backoff)
```

**特別說明**：對於事務訊息，只會進行透明重試（transparent retries），網路超時或異常等場景不會進行重試。

### 3. 重試帶來的副作用

不停的重試看起來很美好，但也是有副作用的，主要包括兩方面：**訊息重複，服務端壓力增大**

-   遠端呼叫的不確定性，因請求超時觸發訊息傳送重試流程，此時客戶端無法感知服務端的處理結果；客戶端進行的訊息傳送重試可能會導致消費方重複消費，應該按照使用者ID、業務主鍵等資訊**冪等處理訊息**。

-   較多的重試次數也會**增大服務端的處理壓力**。

### 4. 使用者的最佳實踐是什麼

**1）合理設定傳送超時時間，傳送的最大次數**

傳送的最大次數在初始化客戶端時配置在 ClientConfiguration；對於某些實時呼叫類場景，可能會導致訊息傳送請求鏈路被阻塞導致業務請求整體耗時高或耗時；需要合理評估每次呼叫請求的超時時間以及最大重試次數，避免影響全鏈路的耗時。

**2）如何保證傳送訊息不丟失**

由於分散式環境的複雜性，例如網路不可達時 RocketMQ 客戶端傳送請求重試機制並不能保證訊息傳送一定成功。業務方需要捕獲異常，並做好冗餘保護處理，常見的解決方案有兩種：

1.  1.  向呼叫方返回業務處理失敗；
    1.  嘗試將失敗的訊息儲存到資料庫，然後由後臺執行緒定時重試，保證業務邏輯的最終一致性。

**3）關注流控異常導致無法重試**

觸發流控的根本原因是系統容量不足，如果因為突發原因觸發訊息流控，且客戶端內建的重試流程執行失敗，則建議執行服務端擴容，將請求呼叫臨時替換到其他系統進行應急處理。

**4）早期版本客戶端如何使用故障延遲機制進行傳送重試？**

對於 RocketMQ 4.x 和 3.x 以下客戶端開啟故障延遲機制可以用：

> producer.setSendLatencyFaultEnable(true)

配置重試次數使用：

> producer.setRetryTimesWhenSendFailed()
> producer.setRetryTimesWhenSendAsyncFailed()

## 消費者消費重試

訊息中介軟體做非同步解耦時的一個典型問題是如果下游服務處理訊息事件失敗，那應該怎麼做呢？

RocketMQ 的訊息確認機制以及消費重試策略可以幫助分析如下問題：

-   **如何保證業務完整處理訊息？**

消費重試策略可以在設計實現消費者邏輯時保證每條訊息處理的完整性，避免部分訊息消費異常導致業務狀態不一致。

-   **業務應用異常時處理中的訊息狀態如何恢復？**

當系統出現異常（當機故障）等場景時，處理中的訊息狀態如何恢復，消費重試具體行為是什麼。

### 1. 什麼是消費重試？

-   **什麼時候認為消費失敗？**  
    消費者在接收到訊息後將呼叫使用者的消費函式執行業務邏輯。如果客戶端返回消費失敗 ReconsumeLater，丟擲非預期異常，或訊息處理超時（包括在 PushConsumer 中排隊超時），**只要服務端服務端一定時間內沒收到響應，將認為消費失敗**。

-   **消費重試是什麼？**  
    消費者在消費某條訊息失敗後，服務端會根據重試策略重新向客戶端投遞該訊息。超過一次定數後若還未消費成功，則該訊息將不再繼續重試，直接被髮送到死信佇列中；

-   **重試過程狀態機**：訊息在重試流程中的狀態和變化邏輯；

-   **重試間隔**：上一次消費失敗或超時後，下次重新嘗試消費的間隔時間；

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

### 2. 訊息重試的場景

需要注意重試是應對異常情況，給予程式再次消費失敗訊息的機會，不應該被用作常態化的鏈路。

**推薦使用**場景：

-   業務處理失敗，失敗原因跟當前的訊息內容相關，預期一段時間後可執行成功；
-   是一個小機率事件，對於大批的訊息只有很少量的失敗，後面的訊息大機率會消費成功，是非常態化的。

**正例：消費邏輯是扣減庫存，極少量商品因為樂觀鎖版本衝突導致扣減失敗，重試一般立刻成功。**

**錯誤使用**場景：

-   消費處理邏輯中使用消費失敗來做條件判斷的結果分流，是不合理的。

**反例：訂單在資料庫中狀態已經是已取消，此時如果收到發貨的訊息，處理時不應返回消費失敗，而應該返回成功並標記不用發貨。**

-   消費處理中使用消費失敗來做處理速率限流，是不合理的。  
    限流的目的是將超出流量的訊息暫時堆積在佇列中達到削峰的作用，而不是讓訊息進入重試鏈路。  
    這種做法會讓訊息反覆在服務端和客戶端之間傳遞，增大了系統的開銷，主要包括以下方面：

-   -   RocketMQ 內部重試涉及寫放大，每一次重試將生成新的重試訊息，大量重試將帶來嚴重的 IO 壓力；
    -   重試有複雜的退避邏輯，內部實現為梯度定時器，該定時器本身不具備高吞吐的特性，大量重試將導致重試訊息無法及時出隊。重試的間隔將不穩定，將導致大量重試訊息延後消費，即削峰的週期被大幅度延長。

### 3. 不要以重試替代限流

上述誤用的場景實際上是組合了限流和重試能力來進行削峰，RocketMQ 推薦的削峰最佳手段為組合**限流和堆積**，業務以保護自身為前提，需要對消費流量進行限流，並利用 RocketMQ 提供的堆積能力將超出業務當前處理的訊息滯後消費，以達到削峰的目的。下圖中超過處理能力的訊息都應該被堆積在服務端，而不是透過消費失敗進行重試。

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/54a31020f50a4cf3a427bfeccaebd515~tplv-k3u1fbpfcp-zoom-1.image "2.png")

如果不想依賴額外的產品/元件來完成該功能，也可以利用一些本地工具類，比如 Guava 的 RateLimiter 來完成單機限流。如下所示，宣告一個 50 QPS 的 RateLimiter，在消費前以阻塞的方式 acquire 一個令牌，獲取到即處理訊息，未獲取到阻塞。

```
RateLimiter rateLimiter = RateLimiter.create(50);
PushConsumer pushConsumer = provider.newPushConsumerBuilder()
    .setClientConfiguration(clientConfiguration)
    // 設定訂閱組名稱
    .setConsumerGroup(consumerGroup)
    // 設定訂閱的過濾器
    .setSubscriptionExpressions(Collections.singletonMap(topic, filterExpression))
    .setMessageListener(messageView -> {
        // 阻塞直到獲得一個令牌，也可以配置一個超時時間
        rateLimiter.acquire();
        LOGGER.info("Consume message={}", messageView);
        return ConsumeResult.SUCCESS;
    })
    .build();
```

### 4. PushConsumer 消費重試策略

PushConsumer 消費訊息時，訊息的幾個主要狀態如下：

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/e885ddfbec4b4974b72ff0b6129cd7cc~tplv-k3u1fbpfcp-zoom-1.image "3.png")

-   Ready：已就緒狀態。訊息在訊息佇列RocketMQ版服務端已就緒，可以被消費者消費；
-   Inflight：處理中狀態。訊息被消費者客戶端獲取，處於消費中還未返回消費結果的狀態；
-   Commit：提交狀態。消費成功的狀態，消費者返回成功響應即可結束訊息的狀態機；
-   DLQ：死信狀態  
    消費邏輯的最終兜底機制，若訊息一直處理失敗並不斷進行重試，直到超過最大重試次數還未成功，此時訊息不會再重試。  
    該訊息會被投遞至死信佇列。您可以透過消費死信佇列的訊息進行業務恢復。

-   **最大重試次數**

PushConsumer 的最大重試次數由建立時決定。

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

-   **重試間隔時間**

-   無序訊息（非順序訊息）：重試間隔為階梯時間，具體時間如下：

**說明**：若重試次數超過 16 次，後面每次重試間隔都為 2 小時。

![3（1）.png](https://p9-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/bbbdfe1b46f944ee97b7861daebc3c81~tplv-k3u1fbpfcp-watermark.image?)

-   順序訊息：重試間隔為固定時間，預設為 3 秒。

### 5. SimpleConsumer 消費重試策略

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

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9854d105d06b4d6b967ba20ef9e24d1e~tplv-k3u1fbpfcp-zoom-1.image "4.png")

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

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

修改訊息不可見時間需要滿足以下條件：

-   **訊息處理未超時**
-   **訊息處理未提交消費狀態**

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

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/356b4dbf569043d18d65e3c30d9aba18~tplv-k3u1fbpfcp-zoom-1.image "5.png")

-   **最大重試次數**

與 PushConsumer 相同。

-   **訊息重試間隔**

訊息重試間隔 = 不可見時間 － 訊息實際處理時長

例如：訊息不可見時間為 30 ms，實際訊息處理用了 10 ms 就返回失敗響應，則距下次訊息重試還需要 20 ms，此時的訊息重試間隔即為 20 ms；若直到 30 ms 訊息還未處理完成且未返回結果，則訊息超時，立即重試，此時重試間隔即為 0 ms。

SimpleConsumer 的消費重試間隔透過訊息的不可見時間控制。

```
//消費示例：使用SimpleConsumer消費普通訊息，主動獲取訊息處理並提交。
ClientServiceProvider provider1 = ClientServiceProvider.loadService();
String topic1 = "Your Topic";
FilterExpression filterExpression1 = new FilterExpression("Your Filter Tag", FilterExpressionType.TAG);

SimpleConsumer simpleConsumer = provider1.newSimpleConsumerBuilder()
        //設定消費者分組。
        .setConsumerGroup("Your ConsumerGroup")
        //設定接入點。
        .setClientConfiguration(ClientConfiguration.newBuilder().setEndpoints("Your Endpoint").build())
        //設定預繫結的訂閱關係。
        .setSubscriptionExpressions(Collections.singletonMap(topic, filterExpression))
        .build();
List<messageview> messageViewList = null;
try {
    //SimpleConsumer需要主動獲取訊息，並處理。
    messageViewList = simpleConsumer.receive(10, Duration.ofSeconds(30));
    messageViewList.forEach(messageView -> {
        System.out.println(messageView);
        //消費處理完成後，需要主動呼叫ACK提交消費結果。
        //沒有ack會被認為消費失敗
        try {
            simpleConsumer.ack(messageView);
        } catch (ClientException e) {
            e.printStackTrace();
        }
    });
} catch (ClientException e) {
    //如果遇到系統流控等原因造成拉取失敗，需要重新發起獲取訊息請求。
    e.printStackTrace();
}
```

-   **修改訊息的不可見時間**

案例：某產品使用訊息佇列來傳送解耦“影片渲染”的業務邏輯，傳送方傳送任務編號，消費方收到編號後處理任務。由於消費方的業務邏輯耗時較長，消費者重新消費到同一個任務時，該任務未完成，只能返回消費失敗。在這種全新的 API 下，使用者可以呼叫可以透過修改不可見時間給訊息續期，實現對單條訊息狀態的精確控制。

```
simpleConsumer.changeInvisibleDuration();
simpleConsumer.changeInvisibleDurationAsync();
```

### 6. 功能約束與最佳實踐

-   **設定消費的最大超時時間和次數**

儘快明確的向服務端返回成功或失敗，不要以超時（有時是異常丟擲）代替消費失敗。

-   **不要用重試機制來進行業務限流**

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

正確示例：如果當前消費速度過高觸發限流，則延遲獲取訊息，稍後再消費。

-   **傳送重試和消費重試會導致相同的訊息重複消費，消費方應該有一個良好的冪等設計**

正確示例：某系統中消費的邏輯是為某個使用者傳送簡訊，該簡訊已經傳送成功了，當消費者應用重複收到該訊息，此時應該返回消費成功。

## 總結

本文主要介紹重試的基本概念，生產者消費者收發訊息時觸發重試的條件和具體行為，以及 RocketMQ 收發容錯的最佳實踐。

**重試策略幫助我們從隨機的、短暫的瞬態故障中恢復，是在容忍錯誤時，提高可用性的一種強大機制。但請謹記 “重試是對於分散式系統來說自私的”，因為客戶端認為其請求很重要，並要求服務端花費更多資源來處理，盲目的重試設計不可取，合理的使用重試可以幫助我們構建更加彈性且可靠的系統。**

歡迎掃描下方二維碼加入釘釘群一起溝通交流～

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/0cd6a165697e442bb5e24946a7cd4660~tplv-k3u1fbpfcp-zoom-1.image "6.png")

點選[此處](https://www.aliyun.com/product/rocketmq)，進入官網瞭解更多詳情～</messageview>

RocketMQ 重試機制詳解及最佳實踐

相關文章