一、背景介绍
在分布式系统中，很多业务逻辑并不是“立刻执行”，而是“到了某个时间再执行”。消息队列的延迟消息能力，正是为这类场景而生。典型使用场景包括：订单超时未支付自动关单、营销活动定时触达、失败请求按退避策略重试等。这些场景的共同特点：消息的产生和消费之间存在一段可预期的时间差。延迟消息将这段“等待”交给消息队列管理，业务方只需在发送时指定到期时间，消费端在消息到期后自动收到投递，逻辑简洁、解耦彻底。但当延迟消息量级从万级攀升到百万级，Apache Pulsar 社区方案会引发：
·消息空洞问题：当延迟消息较多且到期时间分布不均时，大量未到期消息会长时间占据消费位点，形成空洞并导致消费进度无法推进。一旦主题发生重载，内存中尚未持久化的这部分进度就会丢失，已投递的消息被重新拉起，进而引发大规模重复消费。
·内存占用和索引重建耗时：Apache Pulsar 延迟消息索引默认全量加载到内存。消息规模一旦上来，内存占用和索引重建耗时都会成为不容忽视的瓶颈。社区高版本虽引入了 Bucket 化持久存储来缓解，但 Bucket 的管理、合并及元数据存储（依赖 ZooKeeper 的 Cursor Properties）本身又带来了新的复杂性。
二、功能架构
TDMQ Pulsar 大规模延迟消息方案：外部多级时间轮索引，不依赖内存构建延迟索引，主题中只记录最近到期的延迟消息，降低消费空洞规模，使得在百万级场景下内存占用与重复消费风险同时可控。
三、核心特性
·把不同时间跨度的延迟索引拆分到不同维度的索引主题，系统只在临近投递时逐步加载更细粒度的索引，避免全量索引常驻内存。内存中始终只持有当前加载的索引数据，无论延迟消息总量是十万还是百万，内存占用都可控。索引主题的全部消息消费完成后自动删除，无需人工清理。
·延迟消息到期后会从业务主题中读取原始消息并重新写入，消费端跳过尚未到期的消息、仅处理重新写入的到期消息，从而将消息空洞的范围从全量延迟消息收敛到临近投递的分钟级窗口内，避免了大规模空洞的产生。
·TDMQ Pulsar 大规模延迟消息对客户端完全透明——延迟消息照常发送到业务主题，生产消费链路的处理逻辑与原来完全一致，客户端无需任何改造。服务端保证消息 ID 在生产、存储、消费全链路中保持一致，消息查询、消息轨迹等运维能力天然兼容，无需额外适配。
四、使用教程
对客户端侧，新版大规模延迟消息功能和老版社区的延迟消息功能的接入方式相同，详情见：定时和延时消息。
目前大规模延迟消息策略功能为申请制，如果你的业务场景有涉及该能力，请提交工单按需申请。
注意：使用建议：