RocketMQ 5.0 是一次面向云原生（Cloud Native）的重大里程碑升级，其中最核心的架构演进就是引入了存算分离（Storage-Compute Separation）架构。

为了让你更清晰地理解，我们先来看看 4.x 架构到底有什么痛点，然后再看 5.0 是如何通过存算分离解决这些问题的。

---

一、 RocketMQ 4.x 架构面临的痛点

在 RocketMQ 4.x 及之前的版本中，架构主要由 Client（生产者/消费者）、Broker（服务端）和 NameServer（注册中心）组成。Broker 是一个“大单体”，同时承担了计算和存储的职责。 这种架构在云原生时代暴露出了以下几个严重痛点：

1. 计算与存储深度耦合，无法独立扩缩容

• 痛点： Broker 既要处理海量的客户端连接、协议解析、权限校验、消息路由、Rebalance（重平衡）等计算任务，又要负责消息的落盘、主备同步、索引构建等存储任务。
• 后果： 当 CPU/内存遇到瓶颈（比如连接数过多）时，你只能扩容整个 Broker；而扩容 Broker 意味着要进行重的数据迁移（因为 Broker 是有状态的）。反之，如果仅仅是磁盘空间不够，你也需要扩容带计算资源的完整节点，造成资源浪费。

2. “胖客户端（Fat Client）”问题突出

• 痛点： 4.x 的富客户端包含了极其复杂的业务逻辑，比如服务发现、负载均衡、拉取消息、重试机制、Rebalance（重平衡）逻辑等。
• 后果：
  • 多语言支持极其困难： 要为 C++、Go、Python 等语言开发一套与 Java 版完全对齐的客户端成本极高，导致长期以来 RocketMQ 的非 Java 客户端功能羸弱。
  • 客户端升级困难： 一旦有核心逻辑修改（比如发现 Rebalance 的 Bug），需要推动全网所有业务团队升级 SDK，这在大型企业中几乎是不可能完成的任务。
  • 重平衡风暴： 消费者上下线时，Rebalance 是在所有客户端分布式进行的，容易引发数据不一致或短时间的消费停滞。

3. 多协议接入与网络穿透困难

• 痛点： 4.x 默认使用自定义的 Remoting 协议，如果要在服务端支持 gRPC、MQTT、AMQP、HTTP 等协议，必须把这些协议的解析逻辑全塞进 Broker 里，导致 Broker 越来越臃肿。
• 后果： 不利于构建统一的消息网关，且对于 IoT（物联网）等需要海量连接的场景，直接连接 Broker 并不安全且极耗资源。

---

二、 RocketMQ 5.0 的存算分离架构是怎样的？

为了彻底解决上述问题，RocketMQ 5.0 将原来的“大单体 Broker”拆分成了两个独立的角色：Proxy（计算节点） 和 Broker（存储节点）。

1. Proxy（计算节点 —— 专注于“算”）

Proxy 是 5.0 新增的核心组件，它是完全无状态的。

• 协议适配与网关： 负责接管客户端的连接，支持多协议接入（如 gRPC、Remoting、MQTT 等）。
• 权限与路由： 负责身份认证（ACL）、安全防护、流量控制（限流）以及路由发现。
• 接管客户端复杂逻辑（Serverless 化）： 原本客户端做的负载均衡、消费重试、死信管理等逻辑全部上移到 Proxy。
• Pop 消费模式： Proxy 引入了全新的 Pop 机制，将 Rebalance（重平衡）逻辑从客户端移到了 Proxy 服务端。客户端只需要无脑向 Proxy 请求消息即可。

2. Broker（存储节点 —— 专注于“存”）

卸载了沉重的计算负担后，Broker 退化为纯粹的、有状态的数据存储引擎。

• 专注于消息的高性能追加写入（CommitLog）、索引构建（ConsumeQueue、IndexFile）。
• 专注于高可用架构，如主备数据的同步复制（HA）、多副本管理、分级存储（冷热数据分离，将冷数据存入对象存储如 OSS/S3）。

3. Lightweight Client（轻量级客户端）

由于 Proxy 承担了大部分逻辑，5.0 的客户端变得非常“薄”（Thin Client）。

• 全面采用 gRPC 协议进行通信。
• 客户端只保留最基础的发送、接收逻辑，不再关心队列分配和负载均衡。

(注：为了向下兼容，5.0 依然支持 Local 模式，即 Proxy 和 Broker 跑在同一个 JVM 进程里，老用户可以无缝升级；但在云原生大规模部署时，推荐 Cluster 模式，即 Proxy 和 Broker 物理分离部署。)

---

三、 存算分离完美解决了 4.x 的痛点

RocketMQ 5.0 的这套存算分离架构带来了革命性的变化：

1. 极致的弹性伸缩（云原生最爱）：
   • 计算不足时： 比如双十一大促，连接数剧增，只需要秒级扩容无状态的 Proxy 节点即可，不需要搬迁任何数据。
   • 存储不足时： 只需要平滑扩容底层的 Broker 存储集群。资源配比可以从原来的 1:1 变成 N:M，极大提高了资源利用率。
2. 多语言生态彻底爆发：
   • 因为客户端变薄了，加上采用了标准的 gRPC 协议，现在用 Go、C++、C#、Rust、Python 写一个 RocketMQ 客户端变得非常容易。官方也因此推出了全平台的多语言 SDK，功能与 Java 几乎完全对齐。
3. 消除 Rebalance 风暴：
   • 因为采用了无状态的 Proxy + Pop 消费模型，队列的分配在服务端完成。消费者上下线不再会导致整个消费组暂停（Stop The World），单条消息的消费超时也不会阻塞整个队列，彻底解决了长期困扰开发者的消费不均衡和重平衡慢的问题。
4. 业务与基础架构解耦：
   • 后续 RocketMQ 的功能升级、协议扩展、安全补丁，绝大部分只需要在 Proxy 层迭代并发布。基础架构团队可以随时升级服务端，而无需强迫业务团队升级客户端 SDK。

总结

RocketMQ 5.0 的存算分离，本质上是一次“胖客户端瘦身 + 服务端单体解耦”的微服务化改造。它让计算（Proxy）变得轻量敏捷、随需弹性，让存储（Broker）变得专注稳定、安全可靠，从而真正确立了 RocketMQ 作为“云原生消息/事件流平台”的地位。