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

【核心定义】
当消息在 RabbitMQ 队列中因特定条件无法被正常消费时，会被标记为死信（Dead Letter），并被重新路由到预先绑定的死信交换机（DLX）进行处理。

【关键要点】

1. 消息被消费者拒绝且未重新入队：消费者使用 basic.reject 或 basic.nack 并设置 requeue=false 时，消息会变为死信。
2. 消息在队列中存活时间超限：消息的 TTL（Time-To-Live）到期后，若未被消费，则进入死信队列。
3. 队列达到最大长度限制：队列已满（通过 x-max-length 参数设置）时，新消息或队列头部的旧消息（取决于配置）会被转移到死信交换机。
4. 队列被删除或无法投递：消息因队列被删除或路由键不匹配而无法投递时，可能成为死信（需配置备用交换器等机制支持）。

【深度推导/细节】

• TTL 与死信的联动机制：

  • 消息级 TTL：生产者发送消息时设置 expiration 属性，到期后若仍在队列中，则成为死信。
  • 队列级 TTL：通过 x-message-ttl 参数统一设置队列中所有消息的存活时间，到期后集体成为死信。
  • 优先级处理：若同时设置消息级和队列级 TTL，以较短者为准。

• 队列满时的行为策略：

  • 默认丢弃策略：队列满时新消息被丢弃，但通过绑定 DLX 可将其转为死信。
  • 溢出策略配置：通过 x-overflow 参数设置 reject-publish（拒绝新消息并转为死信）或 drop-head（丢弃队列头部消息并转为死信）。

• 死信路由的精确控制：

  • 死信交换机的路由键默认使用原消息的路由键，但可通过 x-dead-letter-routing-key 参数覆盖，实现灵活的路由逻辑。

【关联/对比】

• 死信交换机 vs 备用交换机：
  • 死信交换机处理“已进入队列但无法消费”的消息；备用交换机处理“无法路由到任何队列”的消息，两者解决不同阶段的投递失败问题。
• RabbitMQ 死信 vs Kafka 重试队列：
  • RabbitMQ 通过 DLX 机制实现死信隔离；Kafka 依赖消费者逻辑将失败消息写入独立的重试主题，本质是应用层设计。

『面试官追问』

1. 如何避免死信队列本身的消息堆积？
   • 为死信队列设置独立的 TTL 和长度限制，或部署消费者专门处理死信（如记录日志、人工干预）。
2. 死信消息的属性会变化吗？
   • 死信会保留原始消息的属性和 Body，但 headers 中会添加死亡原因（如 x-first-death-reason）。
3. 如果死信交换机也不存在，会发生什么？
   • 消息将被丢弃，并在 RabbitMQ 日志中生成警告（类似“NO_ROUTE”错误）。

【线程安全与版本差异】

• 线程安全：RabbitMQ 服务端内部通过 Erlang 进程模型保证并发安全，客户端需确保信道（Channel）在单线程内操作。
• 版本差异：
  • RabbitMQ 3.8+ 支持 x-dead-letter-strategy 参数，可配置为 at-most-once（默认）或 at-least-once，控制死信投递的可靠性。
  • 早期版本需手动实现死信的重试机制，新版可通过延迟插件（如 rabbitmq_delayed_message_exchange）与 DLX 结合实现延迟重试。

【最佳实践提示】

• 监控必要性：死信队列的增长可能反映业务逻辑异常（如消费者持续拒收），需配置监控告警。
• 避免循环路由：确保死信交换机未绑定回原队列，否则可能形成死信循环，耗尽系统资源。