RocketMQ 5.0 时代,6 张图带你理解 Proxy!

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

RocketMQ 5.0 为了更好地拥抱云原生,引入了无状态的 Proxy 模块,新的架构图如下:

RocketMQ 5.0 时代,6 张图带你理解 Proxy!_第1张图片

引入 Proxy 模块后,Proxy 承担了协议适配、权限管理、消息管理等计算功能,Broker 则更加专注于存储。这样存储和计算相分离,在云原生环境下可以更好地进行资源调度。

1.Proxy 介绍

RocketMQ 5.0 把客户端的部分功能下沉到 Proxy,Proxy 承接了之前 客户端的计算能力,客户端变得更加轻量级。

1.1 NameServer

从上面的架构图可以看到,Producer/Consumer 不再需要注册到 NameServer,这一部分功能下移到了 Proxy,由 Proxy 跟 NameServer 进行交互,比如查询 TopicRouteData。代码如下:

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

  List messageQueueList = new ArrayList<>();
  Map> brokerMap = buildBrokerMap(proxyTopicRouteData.getBrokerDatas());

  TopicMessageType topicMessageType = messagingProcessor.getMetadataService().getTopicMessageType(topicName);
  for (QueueData queueData : proxyTopicRouteData.getQueueDatas()) {
   String brokerName = queueData.getBrokerName();
   Map 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 适配多种协议,比如 HTTP、gRPC、remoting 等,不同协议的客户端跟 Proxy 建立连接后,Proxy 统一使用 remoting 协议跟 Broker、NameServer 进行通信。

1.2 流量控制

客户端所有的请求都要经过 Proxy,Proxy 将流量分发到 Broker。这样在 Proxy 可以进行流量控制和流量治理。

1.3 POP 模式

我们知道,PUSH 消费模式下,Broker 中的每个 MessageQueue 只能被同一个 Consumer Group 中的一个消费者消费,如下图:

RocketMQ 5.0 时代,6 张图带你理解 Proxy!_第2张图片

PUSH 模式存在下面几个问题:

  1. 消费者最大数量只能等于 MessageQueue 的数量,消费者数量等于 MessageQueue 的数量后,再增加消费者,也不能提高消费能力了;

  2. 客户端的处理逻辑比较多,比如负载均衡、offset 管理、消费失败后的处理(比如失败消息发送回 Broker);

  3. 如果一个消费者机器故障,比如上图中 Consumer0 这个消费者 hang 住了,Topic1 下的两个 MessageQueue 就不能被消费了,导致消息积压,最终只能是重启或下线 Consumer0,Consumer 做重平衡;

  4. 客户端很重,如果要用其他语言编写,工作量很大。

基于 PUSH 模式的不足,RocketMQ 5.0 引入了 POP 消费模式,如下图:

RocketMQ 5.0 时代,6 张图带你理解 Proxy!_第3张图片

跟 PUSH 模式消费者相比,POP 模式客户端有如下优势:

  1. POP 模式消费者可以拉取所有的 MessageQueue,这样即使某个消费者 hang 住,也不会影响某一个 MessageQueue 的消费;

  2. POP 模式消费者不再会重平衡,因为每个消费者默认会去所有的 MessageQueue 拉取消息;

  3. 因为消费者可以拉取所有的 MessageQueue 消息,所以,增加消费者数量,是可以提高消费能力的;

  4. 消费者减少了很多逻辑,变得户端轻量化了,可以方便多语言实现;

  5. 消费者不再维护 offset(offset 由 Broker 维护),变成了无状态组件。

注意:消费者请求 Proxy 时,POP 模式和 PUSH 模式都可以使用,而 Proxy 请求 Broker 时,使用的是 POP 模式,这样可以避免上面提到的一系列问题。如下图:

RocketMQ 5.0 时代,6 张图带你理解 Proxy!_第4张图片

1.4 gRPC

Proxy 基于 gRPC 的标准性、兼容性和多语言传输层代码生成能力,可以轻松构建多语言的轻量级客户端。

2 部署方式

根据不同的场景,Proxy 有两种部署方式,LOCAL 模式和 CLUSTER 模式。

2.1 LOCAL 模式

RocketMQ 4.x 版本 Client 和 Broker 直接通信,RocketMQ 5.0 引入 Proxy 后,Client 和 Broker 之间的通信多了一道网络,也增加了一次序列化和反序列化的过程,这势必增加了延迟,对于延迟敏感的场景可能不能接受。RocketMQ 5.0 引入了 LOCAL 模式部署 Proxy,如下图:

RocketMQ 5.0 时代,6 张图带你理解 Proxy!_第5张图片

Proxy 仍然可以适配多种语言的客户端,而且 Proxy 和 Broker 部署在一起,通信方式使用进程内通信,这样可以减少因为多一道网络带来的延迟,提高吞吐量。同时运维也变得简单,运维成本降低。

LOCAL 模式有一个缺点,因为 Proxy 部署在 Broker 端,受网络环境的限制,对于多网络接入的情况并不友好,成本高。

2.2 CLUSTER 模式

CLUSTER 模式主要用于对延迟不敏感的场景,Proxy 独立部署,在 Proxy 层适配多网络的接入,同时 Proxy 和 Broker 可以独立扩容,互不影响。如下图:

RocketMQ 5.0 时代,6 张图带你理解 Proxy!_第6张图片

2.3 总结

LOCAL 模式更适合对延迟敏感、期望运维成本低、网络接入类型单一的场景。

CLUSTER 模式更适合对延迟要求低、网络接入类型多样的场景。

3 总结

RocketMQ 5.0 跟之前的版本相比,改动很大,更加地拥抱云原生。学习 RocketMQ 5.0,首先要理解 Proxy,希望本文能对您理解 Proxy 有所帮助。

 

 

你可能感兴趣的:(消息队列,rocketmq,proxy)