面经策

RabbitMQ 中消息什么时候会进入死信交换机？ ​

  • 标签：RabbitMQ、消息队列、后端

🏛 业务架构师 ​

消息进入死信交换机（DLX）的三种触发条件，每一种都对应明确的业务处置动作：

  • 被拒绝且不重回队列（basicReject/basicNack 且 requeue=false）：消费端判定消息有问题主动丢弃。业务上用于脏数据拦截——格式错误、风控拒绝的订单进死信，供人工排查而不是无限重试；
  • TTL 过期：延迟队列的物理基础，订单 30 分钟未支付取消就靠它；
  • 队列超过最大长度：老消息被挤出。业务上要慎用，等于"静默丢弃最老的数据"，除非业务明确允许。

我的架构立场：死信队列不是垃圾场，是业务兜底资产。标准做法是：

  1. 每个核心业务队列都配置 DLX + 死信队列，并有独立的消费与告警——死信堆积量是业务健康度的黄金指标，订单死信突然升高往往意味着下游故障或脏数据攻击；
  2. 死信消费侧按业务分级处理：可自动重投的（瞬时故障）有限次重试；不可恢复的落库到异常表，转人工工作流，比如异常订单处理台；
  3. 死信要有 TTL 和归档策略，否则半年后它自己就成了存储事故。

见过不少团队配了死信队列却没人看，出事后才发现几千笔积分没发。没有监控和处置流程的死信设计等于没做，这是我在 MQ 治理评审时的必查项。

🏗 系统架构师 ​

死信交换机（DLX）是 RabbitMQ 的"异常消息归集器"，三种情况进入：

  1. 消息被拒绝：消费端 basic.reject / basic.nack，且 requeue = false；
  2. 消息 TTL 过期：队列设置了 x-message-ttl 或消息自身带 TTL，到期未消费；
  3. 队列达到最大长度：x-max-length / x-max-length-bytes 触发，最老的消息被挤出（overflow=reject-publish 时是新消息被拒）。

死信并不是丢失，DLX 只是普通交换机，绑定一个死信队列后这些消息可被重新消费、告警或人工介入。

架构上的价值：我把 DLX 当成消息系统的"异常停车场"——消费失败消息先进死信队列，配监控告警 + 定时重投或人工处理，形成消费失败的闭环，而不是无限 basicNack 打转。延迟队列（TTL+DLX）也是它的衍生应用。生产上必须给每个核心业务队列配 DLX，否则 poison message 会一直占用队列，这是我在消息队列规范里的强制项。

💻 全栈开发专家 ​

三种情况消息会进入死信交换机（DLX）：

  1. 消费端拒绝：basic.reject 或 basic.nack 且 requeue = false；
  2. 消息过期：TTL 到期（消息级或队列级）；
  3. 队列超长：达到 x-max-length，挤出去的最老消息成为死信。
java
Map<String, Object> args = Map.of(
    "x-dead-letter-exchange", "biz.dlx",
    "x-dead-letter-routing-key", "biz.dead"
);
channel.queueDeclare("biz.queue", true, false, false, args);

我在生产的标准用法：消费失败的消息先投递到重试队列（带 TTL，比如 10s/30s/2min 阶梯），重试队列再绑回原队列实现指数退避；超过最大重试次数才 reject 进真正的死信队列，接告警 + 人工处理/补偿。

两个坑：队列上声明的 DLX 参数改不了，必须重建队列（用 policy 方式设置才能改）；消费死信时记得从 x-death 头里取原始信息和被拒绝原因，不然排查没有线索。