面经策

RabbitMQ 怎么实现延迟队列？ ​

  • 标签：后端、消息队列、RabbitMQ

🏛 业务架构师 ​

RabbitMQ 实现延迟队列有两类主流方案，我按业务复杂度分档：

  • TTL + 死信队列（DLX）：消息设置过期时间，投到没有消费者的"暂存队列"，过期后进入死信交换机路由到真正的消费队列。适合简单延迟。坑在队列头阻塞：TTL 不同的消息排队，队头 10 分钟的消息会挡住后面 30 秒的，必须按延迟档位拆分队列；
  • 延迟插件（rabbitmq_delayed_message_exchange）：交换机层面支持 x-delayed-message，任意延迟时间，实现干净，但插件把消息存内存 Mnesia 表，大流量下有丢失和性能风险，要评估后再上。

业务场景是关键：订单 30 分钟未支付自动取消是标准用例，还有超时自动确认收货、延迟推送提醒、优惠券过期失效。这类需求的共同点是"量大、单条价值不高、允许少量误差"。

我的架构建议：延迟消息只是触发器，真正的关闭动作必须幂等且有兜底——消费端拿订单号做状态机判断（已支付的忽略），再配一个每小时跑一次的兜底扫描任务处理漏网消息。延迟队列丢 1% 不可怕，可怕的是没有对账兜底把 1% 变成客诉。另外如果延迟场景是核心链路且规模大，我会评估 RocketMQ（原生延迟等级）或时间轮+调度中心的方案，RabbitMQ 更适合中小规模的快速落地。

🏗 系统架构师 ​

RabbitMQ 本身没有原生的延迟消息，我实践过三种方案：

  • TTL + 死信队列（DLX）：消息带 TTL 投到普通队列，过期后进入死信交换机路由到消费队列。坑在于队头阻塞：RabbitMQ 只检查队首消息，TTL 10 分钟的消息排在 TTL 1 分钟的前面，后面的会被拖着。所以必须按 TTL 分级，每种延迟一个队列；
  • 延迟消息插件（rabbitmq_delayed_message_exchange）：交换机层面实现，消息存 Mnesia 表，到点投递，任意延迟都支持。代价是集群模式下性能一般、量大后磁盘瓶颈，官方也不建议延迟消息堆积超过百万级；
  • 替代方案：延迟需求复杂（梯度多、量大）时我直接上 Redis ZSet 时间轮或 RocketMQ 18 个延迟级别，架构上更干净。

选型结论：简单、梯度固定的场景用 TTL+DLX；延迟档位多、需要灵活配置用插件；超大规模用专门的延迟中间件。所有方案都必须配合兜底扫描任务——延迟消息丢了业务要有补偿路径。

💻 全栈开发专家 ​

两种方案，生产上我首选延迟插件。

方案一：TTL + 死信交换机（原生，无需插件）

java
// 正常队列绑定 DLX，消息设置 TTL，过期后进入死信队列被消费
args.put("x-dead-letter-exchange", "order.dlx");
channel.queueDeclare("order.delay.queue", true, false, false, args);
AMQP.BasicProperties props = new AMQP.BasicProperties.Builder()
    .expiration("60000")  // 60s 后死信
    .build();

大坑：RabbitMQ 只检查队头消息的过期时间。同队列里 TTL 长的先入队，会把后面 TTL 短的全部堵住——我接手过一个订单超时关闭延迟 20 分钟的故障就是这个原因。规避：每个 TTL 一个队列（队列级 TTL），但队列数会爆炸。

方案二：延迟插件 rabbitmq_delayed_message_exchange（推荐）

java
Map<String, Object> args = Map.of("x-delayed-type", "direct");
// 消息头带 x-delay，由交换机定时投递
props.headers(Map.of("x-delay", 60000));

代价：插件把消息存 Mnesia 表，只保证收到内存未刷盘前不丢，且不支持懒加载队列，堆积多时延迟精度下降。所以超时精度要求高、量大的时候，我会换成 RocketMQ 的延迟等级或 Redis 扫描 key 过期的方案。