RabbitMQ-死信队列（Dead Letter Queue, DLQ）

作者介绍：简历上没有一个精通的运维工程师。请点击上方的蓝色《运维小路》关注我，下面的思维导图也是预计更新的内容和当前进度(不定时更新)。

中间件，我给它的定义就是为了实现某系业务功能依赖的软件，包括如下部分:

Web服务器

代理服务器

ZooKeeper

Kafka

RabbitMQ(本章节)

死信队列（Dead Letter Queue, DLQ）

1. 核心概念与作用

死信队列是一种特殊队列，用于存储因特定原因无法被正常消费的消息。这些消息被称为 “死信”（Dead Letter），通常由于以下原因产生：

• 消息被消费者拒绝（basic.reject 或 basic.nack）且未设置 requeue=true。

• 消息过期（TTL, Time To Live）。

• 队列达到最大长度限制。

作用：

• 防止消息丢失，保留异常消息用于后续分析。

• 解耦正常业务逻辑与异常处理逻辑。

• 实现消息的重试机制。

2. 实现机制

死信队列通过以下步骤配置：

创建普通交换机：通常通过名字来区分普通交换机（dlx_exchange）。

创建普通队列：通常通过名字来区分普通队列（dead_letter_queue）。

绑定：它上面2个普通交换机和普通队列进行绑定。

定义死信队列：这个操作就是配置其他正常队列，当消息不满足要求以后进入我们刚配置的其他交换机。

以上配置仅仅保证消息会被重新进入死信交换机，如果还要进入死信队列还需要添加路由key。

下图的test02队列就是绑定死信队列的配置（DLX）。

在正常队列里面还有个备份交换机的参数：alternate-exchange，在一定程度上也可以起到死信队列的作用，而且有的就直接使用这个参数实现死信功能。

3. 死信处理策略

人工干预：定期检查死信队列，分析失败原因，手动重发或修复。

自动重试：通过定时任务或消息转发机制，将死信重新投递到原队列。

降级处理：对多次失败的消息进行特殊处理（如记录日志、告警）。

4. 最佳实践

为每个业务队列配置独立的死信队列，便于问题定位。

死信队列应设置较大的存储容量，避免死信堆积导致新消息无法进入。

结合监控系统，对死信队列中的消息数量和增长趋势进行实时监控。

运维小路

一个不会开发的运维！一个要学开发的运维！一个学不会开发的运维！欢迎大家骚扰的运维！

关注微信公众号《运维小路》获取更多内容。