RocketMQ LiteTopic 专为 AI 场景设计，应对长时会话、高延迟、大上下文等挑战。支持百万级轻量队列，实现会话级私有通道与细粒度订阅。LiteConsumer 可动态管理节点级订阅，免去 Redis 依赖与广播开销，简化架构，提升稳定性。原生支持断点续传、状态恢复，保障 AI 多轮交互的可靠闭环，构建高效、弹性的新一代通信模型。
1.1 传统应用：单向、无反馈的事件驱动模式
在传统应用的事件驱动场景中，业务逻辑编排通常由人工预先约定，消息生产方成功发送消息后，便无需关注后续的处理逻辑。
下图以注册系统为例：用户发起账户注册请求后，注册系统向 RocketMQ 发送“新用户注册”的消息后便立即返回，无需关心下游的邮件或短信通知系统如何处理。邮件或短信通知系统再分别从 RocketMQ 拉取消息，驱动各自的发送流程。整条业务链路为单向、无反馈的事件驱动模式。
1.2 从单向事件到双向交互：AI 应用对通信提出新挑战
在 AI 应用场景中，业务逻辑编排通常由大模型动态生成，消息生产方需等待并处理响应结果，才能驱动后续的逻辑执行。
下图以典型的 AI 会话场景为例：用户所连接的 Gateway 不仅需要发送请求，还需要处理推理响应结果，并将结果推送给浏览器，形成完整的交互闭环。
结合真实 AI 应用场景的深度调研，我们发现 AI 场景具有四个显著特征，对底层通信模式提出了全新且严苛的挑战：
更长的响应时间：传统互联网应用追求毫秒级响应延时，而 AI 应用的响应时长普遍达到分钟级以上。更关键的是，AI 应用单次业务的运行时间具有高度不可预测性。
更复杂的交互：AI 应用多轮对话持续时间长，对话历史可达数十轮甚至更多。单次上下文传输可能达到几十甚至上百 MB，上下文管理难度高。多 Agent 间协同编排逻辑更加复杂，需要精确状态同步。
更昂贵的计算资源：AI 推理依赖昂贵的 GPU 资源，瞬时高并发流量可能冲击推理服务稳定性，导致算力资源浪费，并且任务失败重试的成本极高。
更精细化的事件驱动：由于计算能力有限，异步事件驱动需要更精准的消费速度控制。同时，必须实现分级的事件驱动策略，以确保高优先级任务优先获得宝贵的计算资源。
1.3 RocketMQ LiteTopic：专为 AI 场景设计的通信模型
为应对上述挑战，Apache RocketMQ 推出了以轻量级通信模型 LiteTopic 为核心的一系列新特性：
轻量级通信模型 —— 为海量会话而生
其核心是百万级轻量资源管理能力。基于极低的资源动态创建开销，可轻松支持海量会话（Session）场景，并提供更细粒度的订阅管理，适用于长时 Session、AI 工作流和 Agent-to-Agent 交互等场景。
企业级上下文管理 —— 让会话状态可靠持久
以连续的消息流完整保存 Session 上下文，通过顺序保障、排他消费等机制严格确保上下文的完整性与一致性。同时原生支持大消息体（数十 MB 甚至更大），轻松满足 AI 场景下庞大数据负载的传输需求。
1.4 LiteTopic 技术解析：百万队列支撑海量并发会话
LiteTopic 基于 RocketMQ 业界领先的百万队列核心技术构建，其底层本质是独立的 Queue。
它为每个独立会话（Session）创建一个专属的、低成本的"私有通道"-即轻量主题（LiteTopic），从而能够以极低的资源开销支撑海量并发会话的需求。
轻量级的 LiteTopic 在消息分配与发送行为上与顺序 Topic 一致（其所属 Queue 由单一 Broker 独占，消息始终路由至该 Broker，而非在多个 Broker 间轮询发送），这种设计天然确保了消息的严格顺序性，并极大降低了资源管理和路由的复杂度。
1.4.1 LiteConsumer 支持单节点粒度的订阅关系管理
与传统消息队列中“同一 Consumer Group ID（CID）必须全局一致订阅相同 Topic”的强约束不同，LiteConsumer 创新性地支持 CID 内各节点按需进行差异化订阅。每个节点可根据实际负载、业务场景或运行时需求，独立订阅不同的 LiteTopic，从而构建更加灵活、弹性的消费拓扑。
这一机制从根本上规避了因订阅关系不一致所引发的消费异常、重复消费或 Rebalance 风暴等问题，显著提升了系统的灵活性、可扩展性与稳定性。同时，它更契合 AI 时代轻量、动态、点对点的交互模式，为构建轻量级请求-响应式消息收发模型提供了原生支持。
1.4.2 LiteConsumer 的核心能力
多节点差异化订阅：同一CID下不同节点可独立订阅各自LiteTopic，实现细粒度、个性化的订阅策略。
动态订阅扩展：运行时实时为单个节点新增LiteTopic订阅，无需重启服务或影响其他节点正常消费。
动态退订能力：运行时实时取消单个节点对特定 LiteTopic 的订阅，实现精准的资源释放与流量治理。
1.5 生产案例：RocketMQ LiteTopic 如何重塑 AI 应用架构？
以下案例基于某客户真实的 AI 应用场景，通过架构对比直观展示采用传统 RocketMQ 通信模型与引入 LiteTopic 轻量级通信模型前后的显著差异。采用 RocketMQ LiteTopic 轻量级通信模型后，客户架构实现了质的提升：不仅彻底移除了对 Redis 的依赖，还避免了广播推送带来的带宽与计算资源浪费。整体架构更轻量，系统稳定性与可靠性也得到显著提升。
1.5.1 改造前：依赖 Redis + 广播的臃肿架构
整体的业务流程步骤如下：
任务提交：用户请求到达后，应用接入层节点将推理任务写入 Redis。
任务处理：Worker集群扫描 Redis 并处理推理任务，将推理过程中的中间结果以多条顺序消息的形式发送至 RocketMQ。
结果持久化与通知：Consumer 集群顺序消费 RocketMQ 消息，将最终推理结果存入 Redis，并基于 RocketMQ 广播通知所有应用接入层节点。
结果推送：应用接入层节点收到广播消息后，仅当结果归属于自身连接时，才从 Redis 获取完整结果并推送给客户端；否则直接忽略该消息。
传统架构采用"先存储、再广播、后过滤"的模式，在高并发 AI 场景下效率低下且成本高昂：
架构臃肿且脆弱：强依赖组件Redis，增加系统的复杂度和潜在故障点，运维成本高，可用性受限。
资源浪费严重：无效的广播机制导致大量带宽占用，且每个应用接入层节点都需计算密集型过滤操作。
链路冗长低效：数据流转需多次读写 Redis，通信链路长、延迟高，应用接入层节点宕机后会话状态将全部丢失，严重影响用户体验。
1.5.2 改造后：基于 RocketMQ LiteTopic 的极简可靠架构
引入 LiteTopic 后，业务流程被大幅简化，实现了端到端的可靠、高效通信：
会话绑定与动态订阅：应用接入层节点在发起推理请求时携带唯一身份标识（如 Session ID），并立即订阅该标识对应的 LiteTopic（无需预创建 consumer group、topic）。
结果持久化发送：智能应用（Worker）根据请求中的身份标识，将推理结果直接发送至对应的 LiteTopic（同样无需预创建）。
精准接收消费：应用接入层节点各自精准接收属于自己response消息，无需过滤，无任何冗余消费。
1.5.3 核心价值：为 AI 会话注入“记忆”，实现断点续传与恢复
客户接入 LiteTopic 轻量级通信模型后，通过将 LiteTopic 与 Session 维度进行细粒度绑定，以极低成本实现了生产级的会话续传与恢复能力。在按照上一小节的流程实现端到端的可靠通信后，在网关机器下线/宕机时：
自动重连：客户端检测到连接断开后，自动发起重连请求。
动态订阅：新接管的应用接入层节点实例根据 Session ID，动态订阅原 session 对应的 LiteTopic（无需预创建）。
断点续传：新应用接入层节点从上次成功消费的 Offset 位点开始拉取消息，精准恢复到故障前的状态（不会丢消息，也不会重复消费已处理的消息）。
恢复会话：自动恢复 Session 的完整上下文，用户完全无感知，业务流程无缝衔接。
