rabbitmq无原生延迟队列，需用ttl+dlx组合实现：消息设ttl过期后，仅当到达队首被检查时才触发死信，必须配置x-message-ttl、x-dead-letter-exchange和x-dead-letter-routing-key三参数，并绑定dlx至消费队列，消费者须监听死信队列。
RabbitMQ 本身不支持原生延迟队列，但用 TTL + 死信队列（DLX）是最稳定、兼容性最好的方案——不需要额外插件，3.5.x 以上所有版本都可用，且生产环境验证充分。
为什么不能直接给消息设 TTL 就完事？
很多人试过在发送时用 message.getMessageProperties().setExpiration("5000") 设置 5 秒过期，却发现消息没进死信队列，甚至直接丢了。这是因为：
- 消息过期后是否变成死信，**取决于它是否还在队列头部等待投递**：RabbitMQ 不会主动扫描整个队列检查每条消息是否过期，只有当消息“走到队首”准备被投递时，才判断它是否已过期；
- 如果队列积压严重，前面有 100 条未消费消息，那第 101 条即使设置了 5 秒 TTL，也可能在队列里卡几十分钟才被检查；
- 单独设置消息 TTL 而不配 DLX，过期消息会被直接丢弃，不会转发——必须显式声明死信交换机和路由键。
必须在队列声明时配置的三个关键参数
真正可控、可预测的延迟行为，依赖队列级 TTL 和 DLX 绑定。以下三个 x-* 参数缺一不可，且必须在 Queue 声明时通过 args 传入：
-
x-message-ttl：单位毫秒，比如30000表示所有消息最多存活 30 秒； -
x-dead-letter-exchange：指定一个已存在的交换机名，如"dlx.order"； -
x-dead-letter-routing-key：指定转发到死信队列时使用的路由键，如"order.delayed"。
注意：x-dead-letter-exchange 必须是普通交换机（DirectExchange 或 TopicExchange），不能是 FanoutExchange（它不认 routing key，会导致死信无法精准路由）。
RabbitMQ 4.2.3
下载
RabbitMQ 4.2.3 是 2026 年初发布的重要稳定更新版本，重点修复了 Khepri 元数据存储相关问题，并改进了监控性能。对于使用 Docker、Kubernetes 或微服务架构的开发团队来说，该版本兼容性和稳定性表现较好。
消费者为什么收不到延迟消息？常见绑定漏项
即使队列和死信交换机都声明了，消息仍可能“消失”或卡住，大概率是绑定关系断了：
- 死信交换机（
dlx.order）必须绑定到一个真实存在的死信队列（如order.dlx.queue），且绑定时的routingKey必须和队列声明里的x-dead-letter-routing-key完全一致； - 正常队列（
order.ttl.queue）的绑定对象是业务交换机（如order.exchange），不是死信交换机——DLX 是自动触发的，不参与初始路由； - 消费者必须监听死信队列（
order.dlx.queue），而不是原始的order.ttl.queue；监听后者只会收到未过期就立刻被消费的消息，完全失去延迟意义。
延迟精度和性能隐患要心里有数
这个方案不是“到点就发”，而是“过期后尽快转发”，实际延迟受两个隐性因素影响：
- 队列中消息堆积量：前面消息处理慢，后面消息即使过期也得排队等轮到自己被检查；
- RabbitMQ 内部检查频率：不是实时扫描，存在毫秒级偏差（通常
如果你需要精确到秒级、且延迟时间动态可变（比如每条消息延迟 3s / 15s / 2min 不等），TTL+DLX 会很别扭——这时该考虑 rabbitmq-delayed-message-exchange 插件，但它要求服务端启用，且不适用于 RabbitMQ 3.5.6 及更早版本。
