RocketMQ5.0时代,6张图带你理解Proxy!

成都创新互联公司是一家专注于网站制作、成都网站建设与策划设计,衢州网站建设哪家好?成都创新互联公司做网站,专注于网站建设10余年,网设计领域的专业建站公司;建站业务涵盖:衢州等地区。衢州做网站价格咨询:18980820575

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

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

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

1、Proxy 介绍

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

(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 进行通信。

(2)流量控制

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

(3)POP 模式

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

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

  1. 消费者最大数量只能等于 MessageQueue 的数量,消费者数量等于 MessageQueue 的数量后,再增加消费者,也不能提高消费能力了;
  2. 客户端的处理逻辑比较多,比如负载均衡、offset 管理、消费失败后的处理(比如失败消息发送回 Broker)。
  3. 如果一个消费者机器故障,比如上图中 Consumer0 这个消费者 hang 住了,Topic1 下的两个 MessageQueue 就不能被消费了,导致消息积压,最终只能是重启或下线 Consumer0,Consumer 做重平衡。
  4. 客户端很重,如果要用其他语言编写,工作量很大。

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

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

  1. POP 模式消费者可以拉取所有的 MessageQueue,这样即使某个消费者 hang 住,也不会影响某一个 MessageQueue 的消费;
  2. POP 模式消费者不再会重平衡,因为每个消费者默认会去所有的 MessageQueue 拉取消息。
  3. 因为消费者可以拉取所有的 MessageQueue 消息,所以,增加消费者数量,是可以提高消费能力的。
  4. 消费者减少了很多逻辑,变得户端轻量化了,可以方便多语言实现。
  5. 消费者不再维护 offset(offset 由 Broker 维护),变成了无状态组件。

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

(4)gRPC

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

2、部署方式

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

(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)CLUSTER 模式

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

(3)总结

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

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

3、总结

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

分享标题:RocketMQ5.0时代,6张图带你理解Proxy!
当前网址:http://www.hantingmc.com/qtweb/news45/77945.html

网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等

广告

声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联