死信队列

1. 什么是死信队列

死信队列（Dead-Letter Queue，DLQ）是 RabbitMQ 中专门用于存放无法被正常消费的消息的特殊队列。当消息满足过期、队列满、消费拒绝这三个触发条件时，会被从原队列转发到死信队列，核心作用是避免消息丢失、便于后续排查和重试消费，是 RabbitMQ 保证消息可靠性的重要机制。
死信队列并非 RabbitMQ 的原生队列类型，而是普通队列被标记为 “死信队列”后形成的特殊队列，对应的还有死信交换机（Dead-Letter Exchange，DLX）—— 专门用于接收死信消息的交换机。

2. 死信队列的三大触发条件

条件 1：消息过期（TTL）

当消息设置了消息级别的 TTL（Time To Live，过期时间），或队列设置了队列级别的 TTL，消息在队列中等待消费的时间超过 TTL 后，会变成死信消息。
场景：比如下单后 30 分钟未支付的订单消息，设置 TTL 为 30 分钟，超时后消息变为死信，被转发到死信队列，后续由专门的服务处理订单关闭、库存释放。

条件 2：队列达到最大长度（队列满）

当队列被配置了最大消息数 / 最大存储空间，且队列中的消息数量达到上限时，后续发送到该队列的消息会变成死信（或被丢弃，取决于配置）。
场景：比如秒杀活动中，RabbitMQ 的订单队列设置了最大长度，当并发请求超过队列承载能力时，超出的消息会成为死信，避免队列过载导致整个服务崩溃。

条件 3：消费者拒绝消费且不重新入队

消费者接收到消息后，因业务异常（如数据库连接失败、消息数据错误）调用basic.reject或basic.nack方法拒绝消费，且设置requeue=false（不重新将消息放回原队列），此时消息会变成死信。
场景：比如消费者处理消息时，发现消息中的用户 ID 不存在，属于无效数据，拒绝消费且不重新入队，消息进入死信队列，后续由运维人员排查数据问题。

3. 死信队列的核心工作流程

结合 RabbitMQ 的组件，清晰说明死信消息的传递过程，这是理解死信机制的关键：

为原业务队列配置死信交换机（DLX）和死信路由键（Dead-Letter Routing Key）；
创建死信队列，并将其与死信交换机通过指定的路由键绑定；
当原队列中的消息满足死信触发条件时，RabbitMQ 会自动将该消息从原队列删除，并转发到配置的死信交换机；
死信交换机根据死信路由键和绑定规则，将死信消息转发到对应的死信队列；
开发人员通过监听死信队列，或手动查看死信队列中的消息，进行问题排查、重试消费或人工处理。

4. 死信队列的配置方式

为原队列设置x-dead-letter-exchange（指定死信交换机）、x-dead-letter-routing-key（指定死信路由键）。

// 1. 配置死信交换机
@Bean
public DirectExchange dlxExchange() {
    return new DirectExchange("order.dlx.exchange", true, false);
}

// 2. 配置死信队列，并绑定到死信交换机
@Bean
public Queue dlxQueue() {
    return QueueBuilder.durable("order.dlx.queue").build();
}

@Bean
public Binding dlxBinding() {
    return BindingBuilder.bind(dlxQueue()).to(dlxExchange()).with("order.dlx.key");
}

// 3. 配置原业务队列，指定死信交换机和路由键
@Bean
public Queue businessQueue() {
    return QueueBuilder.durable("order.business.queue")
            .withArgument("x-dead-letter-exchange", "order.dlx.exchange") // 死信交换机
            .withArgument("x-dead-letter-routing-key", "order.dlx.key") // 死信路由键
            .withArgument("x-message-ttl", 1800000) // 队列级别TTL，30分钟
            .withArgument("x-max-length", 10000) // 队列最大长度
            .build();
}

5. 死信队列实际应用场景

死信队列的应用场景围绕 “异常消息兜底” 展开，主要包括：

订单超时未支付：订单创建后发送消息到业务队列，设置 TTL 为 30 分钟，超时后消息进入死信队列，死信队列的消费端处理订单关闭、库存回滚、优惠券返还；
无效消息排查：消费者接收到格式错误、数据缺失的消息时，拒绝消费并送入死信队列，开发人员通过分析死信消息，定位生产端的问题；
流量削峰兜底：秒杀 / 抢购场景中，业务队列设置最大长度，超出的消息进入死信队列，后续可通过定时任务重试消费，避免消息丢失；
服务降级后的消息处理：当消费端服务因故障降级（如停止消费），消息在原队列堆积并过期，进入死信队列，待服务恢复后从死信队列重试消费。

6. 使用死信队列的注意事项

说明注意事项，体现你对死信机制的深度理解，避免踩坑：

死信队列也需要监控：死信队列并非 “消息垃圾桶”，如果死信消息堆积过多，会占用磁盘空间，需及时监控并处理；
避免死信消息循环：如果死信队列中的消息再次满足死信条件（如设置了 TTL），会导致消息在死信队列中反复成为死信，最终被丢弃，需为死信队列避免配置死信相关参数；
合理设置重试策略：对于可重试的死信消息（如临时网络故障），可通过定时任务从死信队列重发到业务队列；对于不可重试的消息（如数据错误），需人工介入处理；
区分消息级别和队列级别 TTL：消息级别 TTL 是每个消息的过期时间，队列级别 TTL 是队列中所有消息的统一过期时间，队列级别 TTL 的优先级更高（相同时间，如果不是相同时间，时间短的优先），且消息过期后并非立即被删除，而是在被 RabbitMQ 轮询到的时候才会处理。