RocketMQ 5.0 时代,6 张图带你理解 Proxy!
大家好,我是君哥。今天来聊一聊 RocketMQ 5.0 中的 Proxy。
RocketMQ 5.0 为了更好地拥抱云原生,引入了无状态的 Proxy 模块,新的架构图如下:
引入 Proxy 模块后,Proxy 承担了协议适配、权限管理、消息管理等计算功能,Broker 则更加专注于存储。这样存储和计算相分离,在云原生环境下可以更好地进行资源调度。
1.Proxy 介绍
RocketMQ 5.0 把客户端的部分功能下沉到 Proxy,Proxy 承接了之前 客户端的计算能力,客户端变得更加轻量级。
1.1 NameServer
从上面的架构图可以看到,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 适配多种协议,比如 HTTP、gRPC、remoting 等,不同协议的客户端跟 Proxy 建立连接后,Proxy 统一使用 remoting 协议跟 Broker、NameServer 进行通信。
1.2 流量控制
客户端所有的请求都要经过 Proxy,Proxy 将流量分发到 Broker。这样在 Proxy 可以进行流量控制和流量治理。
1.3 POP 模式
我们知道,PUSH 消费模式下,Broker 中的每个 MessageQueue 只能被同一个 Consumer Group 中的一个消费者消费,如下图:
PUSH 模式存在下面几个问题:
- 消费者最大数量只能等于 MessageQueue 的数量,消费者数量等于 MessageQueue 的数量后,再增加消费者,也不能提高消费能力了;
- 客户端的处理逻辑比较多,比如负载均衡、offset 管理、消费失败后的处理(比如失败消息发送回 Broker);
- 如果一个消费者机器故障,比如上图中 Consumer0 这个消费者 hang 住了,Topic1 下的两个 MessageQueue 就不能被消费了,导致消息积压,最终只能是重启或下线 Consumer0,Consumer 做重平衡;
- 客户端很重,如果要用其他语言编写,工作量很大。
基于 PUSH 模式的不足,RocketMQ 5.0 引入了 POP 消费模式,如下图:
跟 PUSH 模式消费者相比,POP 模式客户端有如下优势:
- POP 模式消费者可以拉取所有的 MessageQueue,这样即使某个消费者 hang 住,也不会影响某一个 MessageQueue 的消费;
- POP 模式消费者不再会重平衡,因为每个消费者默认会去所有的 MessageQueue 拉取消息;
- 因为消费者可以拉取所有的 MessageQueue 消息,所以,增加消费者数量,是可以提高消费能力的;
- 消费者减少了很多逻辑,变得户端轻量化了,可以方便多语言实现;
- 消费者不再维护 offset(offset 由 Broker 维护),变成了无状态组件。
注意:消费者请求 Proxy 时,POP 模式和 PUSH 模式都可以使用,而 Proxy 请求 Broker 时,使用的是 POP 模式,这样可以避免上面提到的一系列问题。如下图:
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,如下图:
Proxy 仍然可以适配多种语言的客户端,而且 Proxy 和 Broker 部署在一起,通信方式使用进程内通信,这样可以减少因为多一道网络带来的延迟,提高吞吐量。同时运维也变得简单,运维成本降低。
LOCAL 模式有一个缺点,因为 Proxy 部署在 Broker 端,受网络环境的限制,对于多网络接入的情况并不友好,成本高。
2.2 CLUSTER 模式
CLUSTER 模式主要用于对延迟不敏感的场景,Proxy 独立部署,在 Proxy 层适配多网络的接入,同时 Proxy 和 Broker 可以独立扩容,互不影响。如下图:
2.3 总结
LOCAL 模式更适合对延迟敏感、期望运维成本低、网络接入类型单一的场景。
CLUSTER 模式更适合对延迟要求低、网络接入类型多样的场景。
3 总结
RocketMQ 5.0 跟之前的版本相比,改动很大,更加地拥抱云原生。学习 RocketMQ 5.0,首先要理解 Proxy,希望本文能对您理解 Proxy 有所帮助。
文章转载自公众号:君哥聊技术