RabbitMQ 怎么实现延迟队列？

RabbitMQ 延迟队列实现方案详解

RabbitMQ 本身不直接提供延迟队列功能，但可通过 TTL + 死信交换机（DLX） 或 rabbitmq_delayed_message_exchange 插件 两种主流方案模拟实现消息的延迟投递。

TTL + DLX 方案（原生方案）
- 原理：为消息或队列设置 TTL（生存时间），过期后消息成为“死信”，被自动路由到绑定的死信交换机，进而投递到目标队列。
- 实现步骤： a. 创建业务队列 A，为其设置 x-dead-letter-exchange（绑定死信交换机）和 x-dead-letter-routing-key。 b. 为队列 A 设置 x-message-ttl（队列级别 TTL）或为每条消息设置 expiration 属性（消息级别 TTL）。 c. 创建死信交换机 DLX 和目标队列 B，消费者监听队列 B。
插件方案（rabbitmq_delayed_message_exchange）
- 原理：安装官方插件，使用自定义的 x-delayed-message 类型交换机，消息在交换机层暂存并延迟投递，无需死信机制。
- 优势：延迟精度更高，无需创建多队列，管理更简洁。
方案对比与选型
- TTL+DLX：无需插件，兼容性好；但队列多、管理复杂，且队列级别 TTL 存在 FIFO 延迟问题（队头消息阻塞后续消息）。
- 插件方案：功能强大、使用简单；但需安装插件，且消息在交换机内存中，节点重启可能丢失（除非持久化）。

问题根源：队列级别 TTL 下，RabbitMQ 只检查队头消息是否过期。若队头消息 TTL 很长，即使后面消息已到期，也不会被投递。
解决方案：
- 使用消息级别 TTL：为每条消息设置独立的 expiration。但注意：RabbitMQ 仅在投递消息时检查过期，大量消息积压时性能下降。
- 多级延迟队列：创建多个不同 TTL 的队列（如 5s、10s、30s），消息按延迟时间路由到对应队列。需额外维护队列。

追问 1：“如果使用 TTL+DLX，消息级别 TTL 和队列级别 TTL 同时设置，以哪个为准？”
- 答：以较小的值为准。RabbitMQ 会计算 min(消息TTL, 队列TTL) 作为实际过期时间。
追问 2：“延迟队列的消息大量堆积会导致什么问题？”
- 答：
  - TTL+DLX 方案：内存占用高，过期检查性能下降（尤其是消息级别 TTL）。
  - 插件方案：Mnesia 表过大可能影响交换机性能，极端情况导致内存溢出。
  - 通用问题：延迟时间不准确，业务逻辑滞后。
追问 3：“如何确保延迟消息不丢失？”
- 答：
  - 消息持久化：设置 delivery_mode=2，交换机、队列均声明为持久化。
  - 插件方案：确保 x-delayed-message 交换机声明为持久化。
  - 确认机制：启用生产者确认（publisher confirm）和消费者手动确认（manual ack）。
追问 4：“为什么 RabbitMQ 不原生支持延迟队列？”
- 答：设计哲学不同。RabbitMQ 核心是可靠路由，延迟属于业务层语义。官方更推荐通过插件或组合现有功能实现，保持核心轻量。