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

RocketMQ 5.0 為了更好地?fù)肀г圃肓藷o狀態(tài)的 Proxy 模塊，新的架構(gòu)圖如下：

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

1、Proxy 介紹

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

（1）NameServer

從上面的架構(gòu)圖可以看到，Producer/Consumer 不再需要注冊到 NameServer，這一部分功能下移到了 Proxy，由 Proxy 跟 NameServer 進(jìn)行交互，比如查詢 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 進(jìn)行通信。

（2）流量控制

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

（3）POP 模式

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

PUSH 模式存在下面幾個(gè)問題：

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

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

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

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

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

（4）gRPC

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

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 部署在一起，通信方式使用進(jìn)程內(nèi)通信，這樣可以減少因?yàn)槎嘁坏谰W(wǎng)絡(luò)帶來的延遲，提高吞吐量。同時(shí)運(yùn)維也變得簡單，運(yùn)維成本降低。

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

（2）CLUSTER 模式

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

（3）總結(jié)

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

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

3、總結(jié)

RocketMQ 5.0 跟之前的版本相比，改動(dòng)很大，更加地?fù)肀г圃?。學(xué)習(xí) RocketMQ 5.0，首先要理解 Proxy，希望本文能對您理解 Proxy 有所幫助。