RocketMQ5.0 Proxy

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

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

介绍

RocketMQ5.0把部分功能下沉到Proxy，Proxy承接了之前客户端的计算能里，客户端变得更加轻量级

NameServer

从上面的架构图可以看到，Producter/Consumer不再需要注册到NameServer，这一部分下移到了Proxy，由Proxy跟NameServer进行交互，比如查询TopicRouteData

public class CompletableFuture {
    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 进行通信。

流量控制

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

POP模式

我们知道，PUSH消费模式下，Borker中的每个MessageQueue只能被同一个ConsumerGroup中的一个消费者消费如图

Push模式存在下面几个问题

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

基于PUSH消费模式的不足，RocketMQ5.0引入了POP消费模式，如下图：