RocketMQ 5.5 的 Lite Topic：为 AI 改的消息模型值不值得跟

2026-09-24 Aryee 0

RocketMQ 这两年的演进方向，比多数人的预期更具体：它在为 AI 场景改消息模型。

不是口号。5.5.0（2026 年 4 月 10 日发布）把 Lite Mode 作为该版本的新特性列在第一位，对应 RIP-83「Lite Topic: A New Message Model」。5.5.1（2026 年 8 月 20 日）的维护说明里，稳定性和性能修复覆盖了分级存储、Lite Mode、Proxy 与存储层——也就是说这个新模型不是写完就发布，是在被真实压。

这篇想说的是三件事：它到底在解什么问题、跟不跟这个特性、以及 4.x 的人现在该干什么。

Lite Topic 解的是「主题数量爆炸」

传统用法里一个 Topic 是很重的对象：它有队列数、有订阅关系、有消费位点、有路由信息，还要在 NameServer 里占一份元数据。所以「一个业务域一个 Topic、几十个队列」是常态，几千个 Topic 就已经让元数据同步吃紧。

多 Agent 会话的用法完全不一样：每个会话、每个任务、每个 Agent 实例都可能需要一条独立的、有序的事件流。 如果每个都建成传统 Topic，规模立刻是十万到百万级——这个数量级下，Topic 这个抽象本身就成了瓶颈，而不是它的存储。

Lite Mode 的做法是把这个负担拆掉：官方描述里它是一个「资源消耗更低的轻量订阅模式」，自带完整的生命周期管理、事件分发、订阅注册、消息处理与指标监控，实现上新增了 lite 消息处理器、长轮询服务、控制处理器和对应协议。

但它有几个约束必须先看，否则会把一个「轻量」的东西当成通用 Topic 用：

约束	含义
版本门槛	服务端 ≥ 5.5.0，且客户端走 gRPC SDK（≥ 5.1.0）。Remoting 客户端拿不到这套模型
生命周期	Lite Topic 在客户端 `setLiteTopic` 时自动创建，过期自动删除——没有「先建再用」这一步，也没有控制台里的批量管理入口
队列数	一个 Lite Topic 只有一个队列。不要按传统 Topic 的思路去算并行度
订阅规模	单个消费者可订阅的量级在数千这一档，不是「无限」
可观测性	指标侧目前只有「堆积（backlog）」这一个数，没有与传统 Topic 等量的细粒度指标

最后一条在排期时最容易被忽略：「订阅关系是否滞后」「某个 Lite Topic 的消费 TPS」这类问题，现成指标答不了。如果一个流的健康度必须被监控，那它现在还不该是 Lite Topic。

官方发布材料对这一层的描述停在量级上——「百万级 LiteTopic」这一档，没有给出可用于核对的生产 TPS。这一点本身就有信息量：它是一个用来承载「每个用户一条流」的模型，不是一个可以拿来算并行度的队列。谁要是把某个具体数字抄进你的选型材料，问一句出处，多半问不到官方发布说明里。

社区材料里能看到更具体的说法（承载量、TPS、某些产品内部怎么用），这些不在官方发布材料里。要不要跟的判断不依赖那些数字：只看下一节那三个问题。

判断要不要跟，先问三个问题

这个特性很容易让人心动，但绝大多数团队的答案应该是「先不用」。我的三条判断：

一、你的主题数是不是随终端用户/会话数线性增长？ 如果不是——比如 Topic 数量由业务功能决定，一年涨不了几个——那 Lite Mode 解决的问题你根本没有。此时引入它只增加一条新的客户端协议路径要维护。

二、你能不能接受 Proxy 形态？ Lite Mode 的长轮询与控制能力落在 Proxy 这一层。RocketMQ 5.x 本来就同时支持 Remoting 与 gRPC 两套协议，Proxy 是这套演进的承载点。

这里有一个好消息和一个被夸大的坏消息。好消息是 Proxy 有两种部署形态：独立集群（Cluster），或者直接跟 Broker 同进程拉起（启动参数加 --enable-proxy）。官方对后者的说法是「与 4.0 架构完全一致」——也就是说，存量 4.x 部署不必先加一层独立 Proxy 就能升 5.x，这一点在很多二手文章里被写成了「必须上 Proxy 集群」。被夸大的坏消息是：不管哪种形态，客户端都得换成走 gRPC 的新 SDK，而新增一个协议入口就等于新增一处要管的连接、超时和 TLS。

所以我的判断是：跟这个特性的真实成本不在 Proxy 的拓扑，而在客户端整批换代。这一步的成本，比消息模型本身的收益更容易被低估。

三、有没有替代方案能撑住？ 会话级事件流的另一条路是用一张表：session_id + seq，加一个轻量轮询或者长连接推送。这条路在百万级会话下会遇到明显的存储压力——但很多团队的实际量级是几千。如果几千就能满足，就不要为百万的方案付运维账。

我的结论倾向是：Agent 平台型系统值得评估，业务系统集成不值得。 前者主题数确实由用户量决定，后者不是。

5.5 这条线上另外三处值得注意的

这三条比 Lite Mode 更容易落到你身上：

一、5.5.1 把 DLedger 旧模式正式弃用（deprecate legacy Broker DLedger mode）。 同时 fastjson 1.x 从发行包里移除、fastjson2 升到 2.0.63、DLedger 升到 0.3.3.4。

对还在用 DLedger 做自动主从切换的部署，这一条要认真排期：官方开始引导走向 Controller 模式，继续停在旧 DLedger 上意味着后面的修复不再覆盖你。fastjson 1.x 下线也值得单独说一句——这是很多老 RocketMQ 部署里最后一个 1.x 依赖，它没了之后，安全扫描报告的组件清单会直接变化。

二、权限模型换了一遍，而且旧版本已经删干净。 ACL 1.0 其实早在 4.4.0 就引入了；5.3.0 引入 ACL 2.0，5.3.x 这一串里 ACL 1.0 被移除（到底停在哪个小版本，官方说明写得比发布记录粗，动手前按你实际用的那个版本实测一次）。这条的时间线很重要：如果部署已经在 5.3.x 以上，旧的 ACL 配置文件不是「不推荐」，是根本不生效——升级后出现「权限看着还在、实际全放开」多半是这个原因。反过来，从 4.x 直跳新版本的项目，权限模型必须重写而不是复用。

三、5.4.0（2025-12-24）把定时消息、事务消息与索引换到 RocksDB 实现上（RIP-82），并实现了优先级消息（RIP-80）。 定时消息从纯时间轮改成 RocksDB 支撑，意味着重启后的恢复行为、磁盘占用画像都变了；优先级消息则是一个新的语义维度。这两条对已经在用定时消息做延迟任务的系统影响最直接——升级时要把「定时消息投递精度」和「重启后未到期消息的恢复」列为必测项。

顺带说一句分级存储（tiered storage）：5.5.1 的维护说明里确实修了它，但我在官方文档站没能找到它的专章页面，所以「它现在是 GA 还是实验性」这个问题我给不出结论。看到这个特性的版本发布说明里出现修复，就把它当成稳定能力来排生产链路，是不成立的。

4.x 到 5.x：这条路比想象的粗

先说一个容易被读错的事实：Apache 社区版最后一个 4.x 发布是 4.9.8（2024 年 2 月 22 日），此后没有 4.x 版本，但官方也没有发过任何「4.x 停止维护」的声明。 所以「4.x 到期了必须升」是 pressure 而不是 policy。真正的信号是另一头：新特性（ACL 2.0、Lite Mode、RocksDB 存储、优先级消息）全部只进 5.x，4.x 只是不再长大。

必须提醒的是：4.x 升 5.x 没有直连升级工具，云厂商的兼容性说明里给出的方式是双写迁移。

下面是会在真实迁移里咬人的差异，说法来自云厂商那份 4.x/5.x 版本差异说明：

维度	4.x	5.x
协议	Remoting + HTTP + gRPC	Remoting + gRPC，HTTP 协议移除
配置项	`name-server`	`endpoints`，名字和语义都变了
广播消费	支持	5.x 的 gRPC SDK 不支持广播消费
生态连接器	—	Flink 等流式连接器只走 Remoting SDK，不是「新 SDK 自动兼容」
Topic 消息类型	混用通常不拦	强校验，一个 Topic 一种类型
定时消息上限	按级别延迟	有明确上限（云厂商那边的说法：共享架构最长 7 天）
老客户端	4.x SDK / ons-client	ons-client 1.8.4 在 JDK 17 上直接起不来，需要 ≥ 1.9.1.Final

几项值得展开：

HTTP 协议移除是最先炸的一类。不少老项目里有一批用 HTTP 收发的生产者（尤其是非 Java 语言，或者早期为了绕过防火墙才选 HTTP 的服务），这些端点在 5.x 上没有对应物，只能换 SDK。

广播消费在 gRPC SDK 上不支持——如果你的架构里有用 MessageModel.BROADCASTING 做本地缓存刷新的，这一条会直接卡住：要么这个 Topic 留在 Remoting SDK 上，要么改设计。这也是为什么「一个集群一刀切升 SDK」不现实，双协议共存要按 Topic 粒度规划。

Topic 消息类型强校验是双写迁移阶段最常见的失败点：老系统里同一个 Topic 既有普通消息又有事务消息的部署并不少见，到 5.x 会被直接拒。所以迁移的第一步不是接新 SDK，是把现有 Topic 按消息类型拆开——这件事涉及生产者改造，是所有步骤里工期最长的一项。

ons-client 与 JDK 17 这一条属于「两个升级撞在一起」：很多团队打算顺带把运行时升到 17/21，结果发现旧客户端不兼容。别把这两件事排在同一个窗口里，出问题时无法定位是哪一边。

最后给一个安全侧的定心丸，也是一句实话：2025 到 2026 这一段时间里，我没有找到 RocketMQ 自身的高危通告——被反复引用的仍是 CVE-2023-33246（影响 4.9.6 / 5.1.1 之前版本）和 CVE-2023-37582。这不等于「不用管安全」，它真正的含义是：上面那几个旧 CVE 至今仍是很多线上部署的实际风险，Namesrv 端口暴露 + 无鉴权这个组合比版本新旧更值得先修。