*作者：凌楚*

在 RocketMQ 5.0 中，更加強調了客戶端型別的概念，尤其是消費者型別。為了滿足多樣的 RocketMQ 中一共有三種不同的消費者型別，分別是 PushConsumer、SimpleConsumer 和 PullConsumer。不同的消費者型別對應著不同的業務場景。

## 消費者型別概覽

本篇文章也會根據不同的消費者型別來進行講述。在介紹不同的訊息型別之前，先明確一下不同 RocketMQ 消費者中的一個通用工作流程：在消費者中，到達客戶端的訊息都是由客戶端主動向服務端請求並掛起長輪詢獲得的。為了保證訊息到達的及時性，客戶端需要不斷地向服務端發起請求（請求是否需要由客戶端主動發起則與具體的客戶端型別有關），而新的符合條件的訊息一旦到達服務端，就會客戶端請求走。最終根據客戶端處理的結果不同，服務端對訊息的處理結果進行記錄。

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

另外 **PushConsumer** 和 **SimpleConsumer** 中還會有一個 ConsumerGroup 的概念，ConsumerGroup 相當於是一組相同訂閱關係的消費者的共同身份標識。而服務端也會根據 ConsumerGroup 來記錄對應的消費進度。同一個 ConsumerGroup 下的訊息消費者將共同消費符合當前訂閱組要求的所有訊息，而不是獨立進行消費。相比較於 **PullConsumer**，**PushConsumer** 和 **SimpleConsumer** 更加適用於業務整合的場景，由服務端來託管消費狀態和進度，相對來說更加的輕量與簡單。  
  
簡單來說：

-   **PushConsumer ：** 全託管的消費者型別，使用者只需要註冊訊息監聽器即可，符合對應訂閱關係的訊息就會呼叫對應的消費方法，是與業務整合最為普遍的消費者型別。

-   **SimpleConsumer：** 解耦訊息消費與進度同步的消費者型別，使用者自主接受來自服務端的訊息，並對單條訊息進行訊息確認。和 PushConsumer 一樣也由服務端託管消費進度，適用於使用者需要自主控制消費速率的業務場景。

-   **PullConsumer：** 使用流處理框架進行管理的消費者型別，使用者按照佇列（Topic 的最小邏輯組成單位）來進行訊息的接收並可以選擇自動或者手動提交消費位點。

## PushConsumer

PushConsumer 是 RocketMQ 目前使用最為廣泛的消費者。使用者只需要確認好訂閱關係之後，註冊相對應的 Listener 即可。符合對應訂閱關係的訊息在由 Producer 發出後，消費者的 Listener 介面也會被即時呼叫，那麼此時使用者需要在 Listener 中去實現對應的業務邏輯。

### 使用簡介

以下是 Push 消費者的使用示例：

```
PushConsumer pushConsumer = provider.newPushConsumerBuilder()
 .setClientConfiguration(clientConfiguration)
    // set the consumer group name.
    .setConsumerGroup(consumerGroup)
    // set the subscription for the consumer.
    .setSubscriptionExpressions(Collections.singletonMap(topic, filterExpression))
    .setMessageListener(messageView -> {
        // handle the received message and return consume result.
        LOGGER.info("consume message={}", messageView);
        return ConsumeResult.SUCCESS;
    })
    .build();
// block the main thread, no need for production environment.
Thread.sleep(Long.MAX_VALUE);
// close the push consumer when you don't need it anymore.
pushConsumer.close();
```

使用者需要根據自己業務處理結果的不同來返回 ConsumeResult.SUCCESS或者 ConsumeResult.FAILURE。當使用者返回 ConsumeResult.SUCCESS時，訊息則被視為消費成功；當使用者返回 ConsumeResult.FAILURE時，則服務端視為消費失敗，會進行該條訊息的退避重試，訊息的退避重試是指，在訊息被消費成功之前，當前訊息會被多次投遞到使用者註冊的 MessageListener 中直到消費成功，而兩次消費之間的時間間隔則是符合退避規律的。

特別的，每個 ConsumerGroup 都會有一個最大消費次數的設定，如果當前訊息的消費次數超過了這個設定，則訊息不會再被投遞，轉而被投遞進入死信佇列。這個消費次數在訊息每次被投遞到 MessageListener 時都會進行自增。譬如：如果訊息的最大消費次數為 1，那麼無論對於這條訊息，當前是被返回消費成功還是消費失敗，都只會被消費這一次。

### 應用場景與最佳實踐

PushConsumer 是一種近乎全託管的消費者，這裡的託管的含義在於使用者本身並不需要關心訊息的接收，而只需要關注訊息的消費過程，除此之外的所有邏輯都在 Push 消費者的實現中封裝掉了，使用者只需要根據每條收到的訊息返回不同的消費結果即可，因此也是最為普適的消費者型別。

MessageListener 是針對單條訊息設計的監聽器介面：

```
/**
* MessageListener is used only for the push consumer to process message consumption synchronously.
 *
 * <p> Refer to {@link PushConsumer}, push consumer will get message from server and dispatch the message to the
 * backend thread pool to consumer message concurrently.
 */
public interface MessageListener {
    /**
     * The callback interface to consume the message.
     *
     * </p><p>You should process the {@link MessageView} and return the corresponding {@link ConsumeResult}.
     * The consumption is successful only when {@link ConsumeResult#SUCCESS } is returned, null pointer is returned
     * or exception is thrown would cause message consumption failure too.
     */
    ConsumeResult consume(MessageView messageView);
}
```

絕大多數場景下，使用方應該快速處理消費邏輯並返回消費成功，不宜長時間阻塞消費邏輯。對於消費邏輯比較重的情形，建議可以先行提交消費狀態，然後對訊息進行非同步處理。

實際在 Push 消費者的實現中，為了保證訊息消費的及時性，訊息是會被預先拉取客戶端再進行後續的消費的，因此在客戶端中存在對已拉取訊息大小的快取。為了防止快取的訊息過多導致客戶端記憶體洩漏，也提前預留了客戶端引數供使用者自行進行設定。

```
// 設定本地最大快取訊息數目為 16 條
pushConsumer.setMaxCachedMessageCount(16);
// 設定本地最大快取訊息佔用記憶體大小為 128 MB
pushConsumer.setMaxCachedMessageSizeInBytes(128 * 1024 * 1024);
```

## SimpleConsumer

相比較 **PushConsumer**，**SimpleConsumer** 則暴露了更多的細節給使用者。在 **SimpleConsumer** 中，使用者將自行控制訊息的接收與處理。

### 使用簡介

以下是 **SimpleConsumer** 的使用示例：

```
SimpleConsumer consumer = provider.newSimpleConsumerBuilder()
    .setClientConfiguration(clientConfiguration)
    // Set the consumer group name.
    .setConsumerGroup(consumerGroup)
    // set await duration for long-polling.
    .setAwaitDuration(awaitDuration)
    // Set the subscription for the consumer.
    .setSubscriptionExpressions(Collections.singletonMap(topic, filterExpression))
    .build();
// Max message num for each long polling.
int maxMessageNum = 16;
// Set message invisible duration after it is received.
Duration invisibleDuration = Duration.ofSeconds(15);
final List<messageview> messages = consumer.receive(maxMessageNum, invisibleDuration);
LOGGER.info("Received {} message(s)", messages.size());
for (MessageView message : messages) {
    final MessageId messageId = message.getMessageId();
    try {
        consumer.ack(message);
        LOGGER.info("Message is acknowledged successfully, messageId={}", messageId);
    } catch (Throwable t) {
        LOGGER.error("Message is failed to be acknowledged, messageId={}", messageId, t);
    }
}
// Close the simple consumer when you don't need it anymore.
consumer.close();
```

在 **SimpleConsumer** 中使用者需要自行進行訊息的拉取，這一動作透過 SimpleConsumer#receive 這個介面進行，然後再根據自己業務邏輯處理結果的不同再對拉取到的訊息進行不同的處理。SimpleConsumer#receive 也是透過長輪詢來接受來自服務端的訊息，具體的長輪詢時間可以使用 SimpleConsumerBuilder#setAwaitDuration 來進行設定。

在 **SimpleConsumer** 中，使用者需要透過 SimpleConsumer#receive 設定一個訊息不重複的時間視窗（或者說關於透過這個介面收到的訊息的一個不可見時間視窗），這個時間視窗從使用者接受到這條訊息開始計時，在這段時間之內訊息是不會重複投遞到消費者的，而超出這個時間視窗之後，則會對這條訊息進行再一次的投遞。在這個過程中，訊息的消費次數也會進行遞增。與 **PushConsumer** 類似的是，一旦消費次數超出 ConsumerGroup 的最大次數，也就不會進行重投了。

![圖片 2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/1336b99e4d6d437f8b9bd19794022a05~tplv-k3u1fbpfcp-zoom-1.image "圖片 2.png")
  
相比較於 **PushConsumer** 而言，**SimpleConsumer** 使用者可以自主控制接受訊息的節奏。SimpleConsumer#receive 會針對於當前的訂閱關係去服務端拉取符合條件的訊息。**SimpleConsumer** 實際上的每次訊息接收請求是按照具體 Topic 的分割槽來 one by one 發起請求的，實際的 Topic 分割槽可能會比較多，因此為了保證訊息接收的及時性，建議綜合自己的業務處理能力一定程度上提高 SimpleConsumer#receive 的併發度。

使用者在接受到訊息之後，可以選擇對訊息使用 ack 或者 changeInvisibleDuration，前者即對服務端表示對這條訊息的確認，與 **PushConsumer** 中的消費成功類似，而 changeInvisibleDuration 則表示延遲當前訊息的可見時間，即需要服務端在當前一段時間之後再向客戶端進行投遞。值得注意的是，這裡訊息的再次投遞也是需要遵循 ConsumerGroup 的最大消費次數的限制，即一旦訊息的最大消費次數超出了最大消費次數（每次訊息到達可見時間都會進行消費次數的自增），則不再進行投遞，轉而進入死信佇列。舉例來說：

-   進行 ack，即表示訊息消費成功被確認，消費進度被服務端同步。

-   進行 changeInvisibleDuration，

1）如果訊息已經超過當前 ConsumerGroup 的最大消費次數，那麼訊息後續會被投遞進入死信佇列

2）如果訊息未超過當前 ConsumerGroup 的最大消費次數，若請求在上一次訊息可見時間到來之前發起，則修改成功，否則則修改失敗。

### 應用場景與最佳實踐

在 **PushConsumer** 中，訊息是單條地被投遞進入 MessageListener來處理的，而在 **SimpleConsumer** 中使用者可以同時拿到一批訊息，每批訊息的最大條數也由 SimpleConsumer#receive 來決定。在一些 IO 密集型的應用中，會是一個更加方便的選擇。此時使用者可以每次拿到一批訊息並集中進行處理從而提高消費速度。

## PullConsumer

**PullConsumer** 也是 RocketMQ 一直以來都支援的消費者型別，RocketMQ 5.0 中全新的 **PullConsumer API** 還在演進中，敬請期待。下文中的 **PullConsumer** 會使用 4.0 中現存的 LitePullConsumer 進行論述，也是當前推薦的方式。

### 使用簡介

現存的 LitePullConsumer 中的主要介面

```
// PullConsumer 中的主要介面
public interface LitePullConsumer {
 // 註冊路由變化監聽器
void registerTopicMessageQueueChangeListener(String topic,
        TopicMessageQueueChangeListener topicMessageQueueChangeListener) throws MQClientException;
    // 將佇列 assign 給當前消費者
    void assign(Collection<messagequeue> messageQueues);
    // 針對當前 assigned 的佇列獲取訊息
    List<messageext> poll(long timeout);
    // 查詢當前佇列在服務端提交的位點
    Long committed(MessageQueue messageQueue) throws MQClientException;
    // 設定是否自動提交佇列位點
    void setAutoCommit(boolean autoCommit);
    // 同步提交佇列位點
    void commitSync();
}
```

在 RocketMQ 中，無論是訊息的傳送還是接收，都是透過佇列來進行的，一個 Topic 由若干個佇列組成，訊息本身也是按照佇列的形式來一個個進行儲存的，同一個佇列中的訊息擁有不同的位點，且位點的大小是隨隨訊息達到服務端的時間逐次遞增的，本質上不同 ConsumerGroup 在服務端的消費進度就是一個個佇列中的位點資訊，客戶端將自己的消費進度同步給服務端本質上其實就是在同步一個個訊息的位點。

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

在 PullConsumer 中將佇列這個概念完整地暴露給了使用者。使用者可以針對自己關心的 topic 設定路由監聽器從而感知佇列的變化，並將佇列 assign 給當前消費者，當使用者使用 LitePullConsumer#poll 時會嘗試獲取已經 assign 好了的佇列中的訊息。如果設定了 LitePullConsumer#setAutoCommit 的話，一旦訊息達到了客戶端就會自動進行位點的提交，否則則需要使用 LitePullConsumer#commitSync 介面來進行手動提交。

### 應用場景與最佳實踐

**PullConsumer** 中使用者擁有對訊息位點管理的絕對自主權，可以自行管理消費進度，這是與 PushConsumer 和 SimpleConsumer 最為本質的不同，這也使得 PullConsumer 在流計算這種需要同時自主控制消費速率和消費進度的場景能得到非常廣泛的應用。更多情況下，PullConsumer 是與具體的流計算框架進行整合的。

如果您對 RocketMQ 感興趣，歡迎掃描下方二維碼加入釘釘群一起溝通交流～

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

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

RocketMQ 的消費者型別詳解與最佳實踐

相關文章