一、什么是死信 Dead Letter
一条消息无法被正常消费，会变成死信，触发转发逻辑，只有满足下面三种情况之一才会成为死信：
- 消费者调用
basicNack / basicReject，并且参数requeue=false，不重回原队列； - 消息在队列设置了 TTL 过期，没人消费自动失效；
- 队列达到最大长度限制，新消息挤掉头部旧消息。
死信不会直接丢弃，而是交给预先绑定的DLX 死信交换机，由交换机路由到专门的死信队列（DLQ）。
二、死信队列核心组成：DLX + DLQ
- DLX（Dead Letter Exchange）死信交换机：普通交换机，类型不限（direct/fanout/topic），专门接收所有死信消息；
- DLQ 死信队列：绑定在 DLX 下，用来存放死信消息，人工排查、补偿处理。
关键配置（给业务队列绑定死信能力）
创建普通业务队列时，附加两个参数：
x-dead-letter-exchange：指定死信交换机名称；x-dead-letter-routing-key：转发死信时使用的路由 key，不填默认复用原消息 routingKey。
三、完整流转流程
- 生产者发送消息 → 业务交换机 → 业务队列；
- 消费者消费消息出现异常，拒绝消息
nack(requeue=false)； - RabbitMQ 识别该消息为死信，自动转发到配置好的 DLX 死信交换机；
- DLX 根据路由 key，把消息投递到死信队列 DLQ；
- 业务侧单独监听 DLQ，处理失败消息：打印异常告警、人工修复后重新投递。
四、死信队列两大核心业务场景
场景 1：存储消费失败消息，兜底不丢数据
最基础用途。消息消费报错（参数非法、数据库异常、第三方接口故障），不直接丢弃，存入死信队列，避免数据丢失，支持事后排查重跑。
场景 2：结合 TTL 实现延迟重试队列（TTL+DLX 延迟方案）
这是企业最常用的重试方案，也是容易和纯死信混淆的点：
- 新建延迟重试队列，设置 TTL（如 10s），同时配置它的 DLX 指向原业务交换机；
- 消费失败后，手动 ack 原消息，再用生产者 API 把消息发进延迟队列；
- 消息在延迟队列等待 10s 过期，自动变成死信，通过 DLX 路由回业务队列再次消费；
- 循环重试，通过 header 记录重试次数，达到上限后再转发到最终死信队列。
这里区分：
- 重试队列只是临时中转队列，它的死信目标是业务队列；
- 真正的 DLQ 最终死信队列，存放重试多次仍失败的消息，不再重试。
五、requeue=true 和 死信的关键区别（高频坑点）
nack(requeue=true)：消息直接扔回原队列头部，不会产生死信，立刻重新消费，极易造成重试风暴，故障时打垮服务；nack(requeue=false)：消息判定为死信，转发 DLX 进入死信队列，不会立刻重试。
六、生产使用规范与避坑
- 死信队列必须单独监听，不能和业务队列共用消费者；收到死信后触发告警（钉钉 / 邮件），及时介入；
- 不要无限重试消息：在消息 Header 记录
x-retry-count，超过 3~5 次转发至最终死信队列，防止无限循环； - 区分两种队列职责：
- 重试队列：用于延迟重试，过期自动回业务队列；
- 死信队列 DLQ：兜底存储彻底失败数据，人工处理；
- 死信消息保留原始 header、body、异常标识，方便定位报错原因；
- 死信队列也要设置过期时间，防止堆积海量无效消息占满磁盘。
七、对比延迟交换机插件方案
TTL+DLX 依赖死信机制实现延迟，无需插件，所有 RabbitMQ 版本通用，但存在队头阻塞； x-delayed-message延迟交换机插件不依赖死信，交换机内部缓存延迟消息，每条消息独立延迟，无阻塞，但需要安装插件。
简短总结
消息 nack 不重回队列、TTL 过期、队列满溢三种情况会产生死信；给业务队列配置 DLX 死信交换机，死信自动路由到死信队列 DLQ；死信队列一是兜底保存消费失败消息防止丢失，二是搭配 TTL 做成延迟重试队列；开发禁止 requeue=true 即时重推，通过死信机制可控重试，达到最大重试次数后转入最终死信人工处理。