大家好，我是君哥。今天來聊一聊 RocketMQ 5.0 中的 Proxy。

RocketMQ 5.0 為了更好地擁抱云原生，引入了無狀態(tài)的 Proxy 模塊，新的架構(gòu)圖如下：

引入 Proxy 模塊后，Proxy 承擔(dān)了協(xié)議適配、權(quán)限管理、消息管理等計算功能，Broker 則更加專注于存儲。這樣存儲和計算相分離，在云原生環(huán)境下可以更好地進行資源調(diào)度。

1、Proxy 介紹

RocketMQ 5.0 把客戶端的部分功能下沉到 Proxy，Proxy 承接了之前 客戶端的計算能力，客戶端變得更加輕量級。

（1）NameServer

從上面的架構(gòu)圖可以看到，Producer/Consumer 不再需要注冊到 NameServer，這一部分功能下移到了 Proxy，由 Proxy 跟 NameServer 進行交互，比如查詢 TopicRouteData。代碼如下：

public CompletableFuture<QueryRouteResponse> queryRoute(ProxyContext ctx, QueryRouteRequest request) {
 CompletableFuture<QueryRouteResponse> future = new CompletableFuture<>();
 try {
  //省略部分代碼
  ProxyTopicRouteData proxyTopicRouteData = this.messagingProcessor.getTopicRouteDataForProxy(
   ctx, addressList, topicName);

  List<MessageQueue> messageQueueList = new ArrayList<>();
  Map<String, Map<Long, Broker>> brokerMap = buildBrokerMap(proxyTopicRouteData.getBrokerDatas());

  TopicMessageType topicMessageType = messagingProcessor.getMetadataService().getTopicMessageType(topicName);
  for (QueueData queueData : proxyTopicRouteData.getQueueDatas()) {
   String brokerName = queueData.getBrokerName();
   Map<Long, Broker> brokerIdMap = brokerMap.get(brokerName);
   if (brokerIdMap == null) {
    break;
   }
   for (Broker broker : brokerIdMap.values()) {
    messageQueueList.addAll(this.genMessageQueueFromQueueData(queueData, request.getTopic(), topicMessageType, broker));
   }
  }

  QueryRouteResponse response = QueryRouteResponse.newBuilder()
   .setStatus(ResponseBuilder.getInstance().buildStatus(Code.OK, Code.OK.name()))
   .addAllMessageQueues(messageQueueList)
   .build();
  future.complete(response);
 } catch (Throwable t) {
  future.completeExceptionally(t);
 }
 return future;
}

Proxy 適配多種協(xié)議，比如 HTTP、gRPC、remoting 等，不同協(xié)議的客戶端跟 Proxy 建立連接后，Proxy 統(tǒng)一使用 remoting 協(xié)議跟 Broker、NameServer 進行通信。

（2）流量控制

客戶端所有的請求都要經(jīng)過 Proxy，Proxy 將流量分發(fā)到 Broker。這樣在 Proxy 可以進行流量控制和流量治理。

（3）POP 模式

我們知道，PUSH 消費模式下，Broker 中的每個 MessageQueue 只能被同一個 Consumer Group 中的一個消費者消費，如下圖：

PUSH 模式存在下面幾個問題：

1. 消費者最大數(shù)量只能等于 MessageQueue 的數(shù)量，消費者數(shù)量等于 MessageQueue 的數(shù)量后，再增加消費者，也不能提高消費能力了；
2. 客戶端的處理邏輯比較多，比如負載均衡、offset 管理、消費失敗后的處理（比如失敗消息發(fā)送回 Broker）。
3. 如果一個消費者機器故障，比如上圖中 Consumer0 這個消費者 hang 住了，Topic1 下的兩個 MessageQueue 就不能被消費了，導(dǎo)致消息積壓，最終只能是重啟或下線 Consumer0，Consumer 做重平衡。
4. 客戶端很重，如果要用其他語言編寫，工作量很大。

基于 PUSH 模式的不足，RocketMQ 5.0 引入了 POP 消費模式，如下圖：

跟 PUSH 模式消費者相比，POP 模式客戶端有如下優(yōu)勢：

1. POP 模式消費者可以拉取所有的 MessageQueue，這樣即使某個消費者 hang 住，也不會影響某一個 MessageQueue 的消費；
2. POP 模式消費者不再會重平衡，因為每個消費者默認會去所有的 MessageQueue 拉取消息。
3. 因為消費者可以拉取所有的 MessageQueue 消息，所以，增加消費者數(shù)量，是可以提高消費能力的。
4. 消費者減少了很多邏輯，變得戶端輕量化了，可以方便多語言實現(xiàn)。
5. 消費者不再維護 offset（offset 由 Broker 維護），變成了無狀態(tài)組件。

注意：消費者請求 Proxy 時，POP 模式和 PUSH 模式都可以使用，而 Proxy 請求 Broker 時，使用的是 POP 模式，這樣可以避免上面提到的一系列問題。如下圖：

（4）gRPC

Proxy 基于 gRPC 的標準性、兼容性和多語言傳輸層代碼生成能力，可以輕松構(gòu)建多語言的輕量級客戶端。

2、部署方式

根據(jù)不同的場景，Proxy 有兩種部署方式，LOCAL 模式和 CLUSTER 模式。

（1）LOCAL 模式

RocketMQ 4.x 版本 Client 和 Broker 直接通信，RocketMQ 5.0 引入 Proxy 后，Client 和 Broker 之間的通信多了一道網(wǎng)絡(luò)，也增加了一次序列化和反序列化的過程，這勢必增加了延遲，對于延遲敏感的場景可能不能接受。RocketMQ 5.0 引入了 LOCAL 模式部署 Proxy，如下圖：

Proxy 仍然可以適配多種語言的客戶端，而且 Proxy 和 Broker 部署在一起，通信方式使用進程內(nèi)通信，這樣可以減少因為多一道網(wǎng)絡(luò)帶來的延遲，提高吞吐量。同時運維也變得簡單，運維成本降低。

LOCAL 模式有一個缺點，因為 Proxy 部署在 Broker 端，受網(wǎng)絡(luò)環(huán)境的限制，對于多網(wǎng)絡(luò)接入的情況并不友好，成本高。

（2）CLUSTER 模式

CLUSTER 模式主要用于對延遲不敏感的場景，Proxy 獨立部署，在 Proxy 層適配多網(wǎng)絡(luò)的接入，同時 Proxy 和 Broker 可以獨立擴容，互不影響。如下圖：

（3）總結(jié)

LOCAL 模式更適合對延遲敏感、期望運維成本低、網(wǎng)絡(luò)接入類型單一的場景。

CLUSTER 模式更適合對延遲要求低、網(wǎng)絡(luò)接入類型多樣的場景。

3、總結(jié)

RocketMQ 5.0 跟之前的版本相比，改動很大，更加地擁抱云原生。學(xué)習(xí) RocketMQ 5.0，首先要理解 Proxy，希望本文能對您理解 Proxy 有所幫助。