回顾：上篇留下的 3 个谜题

​

在上篇《一次 AI 问答，背后是十几个 Agent 在 “传纸条” — RocketMQ Lite Topic 实战》中，我们通过两个真实场景 — AI 编程助手多 Agent 协作 和 大模型记忆服务的"记忆写入" — 看到了 Lite Topic 在 AI 原生应用通信链路里的关键作用。

但读完之后，相信不少读者心里都打着同一个问号：

今天这篇，我们一个个揭开。

TDMQ RocketMQ 与 轻量主题 Lite Topic

为了拥抱 AI 原生应用架构带来的变革，针对 “多 Agent 协作持续时间长、多轮次上下文依赖” 的特点，Apache RocketMQ 在已有的 LMQ（Light Message Queue）能力基础上进一步推出了 Lite Topic 功能。腾讯云 RocketMQ 立足开源社区的底层能力，结合业务诉求做了进一步的产品化设计和优化，在已有的主题模型下推出了 轻量主题 Lite Topic 功能。

与传统 Topic 相比，Lite Topic 有三个关键差异：

• 兼容原有主题模型的前提下，实现了二级数据隔离
• 实现了 单客户端的排他订阅，订阅关系更加灵活
• 自动生命周期管理：发送消息即自动创建，过期无消息即自动删除

基于以上特性，Lite Topic 当前已在腾讯内部业务落地验证，正在逐步对外部客户灰度开放，以实现 大模型会话任务解耦与非阻塞调用，提升 Agent 的吞吐能力和响应速度。

概念模型：两级主题

RocketMQ 的轻量主题（Lite Topic）与主题（Topic，或称为 ParentTopic）存在逻辑上的层级关系：

每个 Lite Topic 都从属于一个 Topic，而一个 Topic 可以关联多个 Lite Topic。

这种两级模型的好处是：业务侧通过 Topic 获得“全局视图”（如全租户的总速率、堆积情况），通过 Lite Topic 获得“细粒度通道”（如某个用户会话的精确监控），一举两得。

（图 1：两级主题模型示意图 —— Topic 与 Lite Topic 的从属关系）

谜题 1 揭秘：百万 Lite Topic 是怎么"轻"起来的

单实例百万级 Lite Topic 自动创建，核心问题是：怎么让“主题”不那么“重”？

生命周期：发送即创建，过期即销毁

Lite Topic 的整个生命周期 无需业务侧关注，支持全自动化管理：

发送时自动创建

当客户端发送消息时，Broker 会检查 Lite Topic 是否已创建；如果没有则会自动创建。

过期后自动删除

创建 Topic 时可以设置 TTL 属性，所有关联的 Lite Topic 都会根据该 TTL 自动过期。过期判断逻辑：若某个 Lite Topic 中最近一条消息的写入时间距当前时间已超过 TTL，则该 Lite Topic 被视为已过期。过期后进入后台异步清理流程，删除其消费位点、消费索引，以及移除内存中与该 Lite Topic 相关的订阅关系等。

这是“轻量”的第一层保证：不让没用的主题“阴魂不散”，避免长尾累积。

存储复用：站在 LMQ 的肩膀上

那核心问题来了：百万级 Lite Topic 怎么不爆掉 Broker 的内存？

这里在代码实现上复用了 RocketMQ 开源社区已有的 LMQ（Light Message Queue）能力。此外，发送到 Lite Topic 的所有消息都会追加写入存储层的同一个物理队列，以确保全局有序性。当 Broker 节点在发布重启期间或发生单机故障时，写入流量会自动切换（Failover）到集群内的其他可用节点，从而优先保障服务可用性。

LMQ 设计之初就是为了支持百万级队列的轻量化存储模型，与 Lite Topic 的应用场景 “主题自动创建 + 百万级规模” 高度契合。因此，Lite Topic 的消费索引构建体系直接复用 LMQ 能力 - 不重造轮子，把成熟能力组合出新价值。

总的来说，Lite Topic 在写入路径上完全沿用 RocketMQ 既有的存储体系。在内核存储层面，它与传统 Topic 无任何结构性差异。这种一致性保证了实现上的简洁性，并显著降低了维护与运维成本。

谜题 2 揭秘：海量订阅怎么不拖垮 Broker

百万级 Lite Topic 不止要 “创建得起”，还要 “订阅得起、分发得起”。我们为 Lite Topic 构建了一套高效的订阅与分发机制，主要包括两部分：

客户端维度的订阅管理

与传统基于消费组（Consumer Group）维护订阅关系的模型不同，Lite Topic 将订阅关系下沉到客户端维度（ClientId）进行管理。

由于不再强依赖 Consumer Group 语义，系统无需维护 Consumer Group 内部的一致性状态。这种弱化 Group 的订阅模型天然更轻量，使得在百万级 Lite Topic 规模下，Broker 仍能保持较低的订阅状态管理开销。

事件驱动的合并拉取（Ready Event Set）

百万订阅下另一个挑战是：消费端怎么高效拉取消息，不被海量空查询拖垮？

这里的解法是引入“就绪事件（Ready Event）”机制：

• 当新消息写入 Lite Topic 并完成消费索引构建后，Broker 立即分发“就绪事件”给相关订阅者
• 每个订阅者维护一个独立的 “就绪事件集合（Ready Event Set）”，其中记录了该客户端所订阅的全部 Lite Topic 的就绪事件
• 当客户端发起 POP 请求时，Broker 直接从就绪事件集合中高效地读取就绪消息

这种机制有两个好处：

• 一次请求合并拉取多个 Lite Topic 的消息 - 大幅减少 RPC 数量
• 避免对存储层产生大量无效查询 - 空 Lite Topic 不会触发任何拉取动作

（图 2：Ready Event Set 合并拉取机制示意图）

谜题 3 揭秘：排他消费 + 最新连接胜出

“最新连接胜出”的排他消费到底是什么机制？

从 Shared 到 Exclusive 的演进

传统的 RocketMQ 消费采用 共享模式（Shared）：Consumer Group 下的所有客户端均衡地消费 Topic 中的消息。这在常规队列场景下没问题，但在 Lite Topic 的会话保持场景下就出现了问题：

用户的会话内容流被多个消费者切片消费 — 意味着同一个会话的 token 流被打散到多个 SSE 网关上，前端 根本拼不回完整对话。

为了适配 Lite Topic 的使用场景（例如会话保持），我们为 RocketMQ 引入了一种全新的 排他消费模式（Exclusive）：

发送给 Lite Topic 的消息只会被 Consumer Group 下的其中一个客户端独占消费。

“最新连接胜出”机制

开启排他消费模式后，Broker 默认会选择 最新连接的客户端作为 Lite Topic 的独占消费者，并通知旧的客户端取消订阅。

这个看似简单的规则，恰恰是上篇场景 2 中 “断线续传” 得以实现的关键：

用户断线 → 网关 A 仍持有订阅
用户重连命中网关 B → 网关 B 发起排他订阅
                  → Broker 触发"最新连接胜出"
                  → 自动踢出网关 A
                  → 网关 B 接管该会话的后续 token

整个过程不需要任何业务侧的协调代码 — 业务侧只需调用 seek(offset) 把位点定位到客户端记录的 lastReceivedOffset+1，剩下的全交给协议。

（图 3：断线续传 + 最新连接胜出机制示意图）

与传统 Topic 的关键差异对比

新增的 TDMQ RocketMQ Lite Topic 功能，对比传统 Topic 有以下优势：

把上篇的 "魔法" 映射到下篇的 "机制"

最后，把上篇的 3 个谜题与下篇的技术机制做一次完整闭环：

Lite Topic 在产品层提供的能力，全部都映射到 RocketMQ 内核可解释、可观测、可演进的机制上——这是我们在做这次能力增强时坚守的设计原则。

结语：AI 原生应用的基础设施还在演进

路漫漫其修远兮，吾将上下而求索。

随着 AI 技术的持续演进，RocketMQ 在 LLM 流式服务、Agent 状态管理、RAG 数据底座、模型推理流水线、多模态数据处理 等场景也将发挥更大价值，为企业构建 AI 原生应用提供坚实的技术基石。

Lite Topic 能力当前已在腾讯云内部多个 AI 业务灰度运行，后续将面向外部客户商业化，欢迎加入 👇 产品交流群沟通了解更多信息！

往期推荐

一次 AI 问答，背后是十几个 Agent 在 “传纸条” — RocketMQ Lite Topic 实战

重磅发布！为 AI 原生应用而生 - TDMQ RocketMQ 轻量主题 Lite Topic！

让 Token 消费看得见、管得住、省得下 - AI 网关成本治理能力解析

智能路由与业务连续性保障：AI 网关如何让大模型稳定跑在生产链路上

TDMQ RabbitMQ 托管版全新推出 4.2：原生支持 AMQP 1.0，吞吐性能翻倍！

扫描下方二维码关注本公众号，

了解更多消息队列、微服务相关信息！

👇 阅读原文，了解 腾讯云 TDMQ RocketMQ Lite Topic 更多信息

文章来源于腾讯云开发者社区，点击查看原文