RabbitMQ 面试里经常把两个问题放在一起问：死信交换机是什么？延迟队列怎么做？这两个问题不是孤立的，因为 RabbitMQ 原生延迟队列的经典实现，就是 TTL + 死信交换机。
一句话概括：死信交换机负责接收"消费失败、消息过期、队列满了"的死信；延迟队列可以利用 TTL 让消息先在等待队列里过期，再通过 DLX 转发到真正的业务队列。
超时未消费
生产者
ttl.direct
ttl.queue
设置 TTL
dl.direct
死信交换机
dl.queue
业务消费
消费者处理订单关闭/定时发布
死信是什么
一个队列里的消息满足下面任意一种情况，就可能变成死信：
| 变成死信的原因 | 说明 |
|---|---|
| 消费者拒绝 | basic.reject 或 basic.nack，并且 requeue=false |
| 消息过期 | 消息 TTL 到期仍然没有被消费 |
| 队列满了 | 队列达到长度限制，较早消息可能被挤出 |
如果队列配置了 dead-letter-exchange，这些死信不会直接消失，而是会被投递到指定交换机。这个交换机就叫死信交换机，也就是 DLX。
reject/nack 且 requeue=false
TTL 到期
队列满了
是
否
Queue 中的消息
发生什么
变成死信
是否配置 dead-letter-exchange
投递到死信交换机 DLX
消息被丢弃或按策略处理
死信交换机本质上仍然是普通交换机，只是它接收的是其他队列转过来的死信消息。
TTL 是什么
TTL 是 Time-To-Live，表示消息可以存活多久。RabbitMQ 里 TTL 常见有两种设置方式：
| TTL 类型 | 设置位置 | 特点 |
|---|---|---|
| 队列 TTL | 队列参数 x-message-ttl |
队列里的所有消息统一过期时间 |
| 消息 TTL | 发送消息时设置 expiration | 每条消息可以有不同过期时间 |
如果消息在 TTL 时间结束后仍然没有被消费，就会变成死信。只要这个队列绑定了 DLX，消息就会被转发到死信交换机。
用 TTL + DLX 实现延迟队列
延迟队列的意思是：消息不是立刻被消费，而是等待一段时间后再被消费。
典型场景：
| 场景 | 延迟动作 |
|---|---|
| 超时订单 | 下单 30 分钟未支付，自动关闭 |
| 限时优惠 | 活动结束后自动下架 |
| 定时发布 | 到点后发布文章、视频或公告 |
TTL + DLX 的实现思路如下：
消费者 业务队列 死信交换机 TTL 队列 生产者 消费者 业务队列 死信交换机 TTL 队列 生产者 不绑定消费者，等待 TTL 过期 发送延迟消息 消息过期，变成死信 根据 dead-letter-routing-key 路由 消费真正的业务消息
这套设计的关键点是：TTL 队列只是"等待室"，真正处理业务的是死信交换机后面的业务队列。
TTL 延迟队列的坑
TTL + DLX 很好理解，但它不是完美的定时任务系统。最容易被追问的是队头阻塞。
如果每条消息自己设置不同 TTL，RabbitMQ 并不会为了后面的短 TTL 消息主动越过前面的长 TTL 消息。过期消息通常要到达队头时才会被丢弃或死信转发，所以可能出现这种情况：
未到期挡在队头
消息 A
TTL 30 分钟
消息 B
TTL 5 秒
消息 C
TTL 10 秒
后面的短 TTL 消息不能按预期立刻死信
这会导致"理论上 5 秒后执行"的消息，实际被前面的长 TTL 消息挡住，延迟变得不稳定。
常见规避方式有三种：
| 方案 | 说明 |
|---|---|
| 固定延迟档位 | 5 分钟、30 分钟、2 小时分别建不同 TTL 队列 |
| 使用 DelayExchange 插件 | 每条消息通过 x-delay 表达延迟时间，语义更直观 |
| 使用专业调度组件 | 延迟精度和任务管理要求高时，用 XXL-JOB、调度表等方案 |
所以 TTL + DLX 更适合延迟档位比较少、精度要求不极端的业务，比如订单 30 分钟超时关闭。
DelayExchange 插件
课件里也提到 RabbitMQ 的延迟队列插件 DelayExchange。它的本质还是交换机，只是在交换机上增加了延迟能力。
使用方式通常是：
- 安装 RabbitMQ 延迟插件。
- 声明交换机时设置
delayed=true。 - 发送消息时在 header 中设置
x-delay，值为延迟毫秒数。 - 延迟时间到后，交换机再把消息路由到队列。
x-delay=30000
等待 30 秒后路由
生产者
DelayExchange
业务队列
消费者
插件方案比 TTL + DLX 更直观，因为消息不需要先进入一个专门的 TTL 等待队列。但它依赖插件安装，线上环境要确认运维和版本支持。
两种延迟方案怎么选
| 方案 | 优点 | 缺点 | 适合场景 |
|---|---|---|---|
| TTL + DLX | 不依赖插件，机制通用 | 队列设计稍绕，消息级 TTL 可能有队头阻塞 | 延迟时间档位少、环境保守 |
| DelayExchange | 使用直观，每条消息可设置 x-delay |
依赖插件 | 延迟时间灵活、运维允许安装插件 |
如果面试官问"延迟队列是不是死信队列"，可以这样答：延迟队列不是死信队列，但可以用死信机制实现。TTL 队列里的消息过期后变成死信，再由死信交换机转发到业务队列，从效果上实现延迟消费。
面试回答模板
可以这样答：
RabbitMQ 中死信是指消息因为消费失败并且不重新入队、TTL 过期、队列满了等原因无法正常消费。如果队列配置了 dead-letter-exchange，这些消息会被投递到死信交换机。延迟队列可以用 TTL + 死信交换机实现：先把消息发到设置了 TTL 的等待队列，队列不绑定消费者，消息过期后变成死信，再通过 DLX 路由到真正的业务队列。项目里常见场景有超时订单、限时优惠和定时发布。不过 TTL 方案要注意消息级 TTL 的队头阻塞问题，如果延迟时间非常灵活或精度要求更高，可以安装 DelayExchange 插件，发送消息时通过
x-delay设置延迟时间。
小结
死信交换机解决的是"异常消息去哪儿"，延迟队列解决的是"消息什么时候消费"。两者结合时，TTL 负责等待，DLX 负责转发。
延迟需求
TTL 等待
过期变死信
DLX 转发
业务队列消费