一、消息成为死信的条件
在RabbitMQ中，消息会在以下三种情况下成为死信：
-
消费者显式拒绝且不重新入队
当消费者调用basic.reject或basic.nack方法，并设置requeue = false时，消息会被标记为死信。此机制适用于需要主动丢弃无效消息的场景，如参数校验失败或业务逻辑不匹配。 -
消息超时未消费
TTL（Time To Live）机制分为两种实现方式：- 队列级别TTL：通过设置队列的
x-message-ttl属性，所有进入该队列的消息均继承此过期时间。计时从消息进入队列开始，到期后若未被消费则成为死信。 - 消息级别TTL：在发送消息时通过
expiration属性单独设置每条消息的存活时间。计时起点同样为消息进入队列，但若队列中存在积压，消息可能不会立即过期（仅在到达队列头部时检查）。
- 队列级别TTL：通过设置队列的
-
队列达到最大容量
当队列通过x-max-length参数设置最大长度限制后，新消息若超出限制会导致最旧的消息被挤出队列成为死信。
二、消息超时的两种方式对比
| 方式 | 作用范围 | 优先级 | 适用场景 |
|---|---|---|---|
| 队列级别TTL | 队列中所有消息 | 若同时设置消息TTL，取较小值生效 | 批量处理具有相同时效性的消息（如订单超时） |
| 消息级别TTL | 单条消息 | 同上 | 动态控制不同消息的过期时间（如优先级任务） |
注意：若两者同时存在，以更早过期的时间为准。例如，队列TTL为30秒，消息TTL为10秒，则消息实际存活时间为10秒。
三、实现延迟队列的两种方法
方法1：TTL + 死信交换机（传统方案）
步骤：
- 配置死信交换机（DLX）
创建正常交换机与队列，通过x-dead-letter-exchange参数将正常队列绑定到死信交换机。 - 设置消息TTL
发送消息时指定expiration属性为20秒，或通过队列属性设置TTL。 - 绑定消费者队列
将消费者监听的队列与死信交换机绑定，消息过期后自动路由至此队列。
局限性：
若队列中存在消息积压，TTL计时不精确（仅检查队列头部消息是否过期）。
方法2：Delayed Exchange插件（推荐方案）
步骤：
- 声明延迟交换机
创建交换机时添加delayed: true属性，声明为延迟类型。 - 发送延迟消息
在消息头中添加x-delay属性（单位：毫秒），例如设置为20000表示延迟20秒。 - 绑定消费者队列
延迟到期后，消息自动路由至绑定队列，消费者正常监听即可。
优势：
计时精确，无需依赖死信机制，且支持每条消息独立设置延迟时间。
四、TTL计时规则详解
- 队列级别TTL：从消息进入队列开始计时，到期后若未被消费则成为死信。
- 消息级别TTL：同样从进入队列开始计时，但仅在到达队列头部时触发过期检查。若队列中存在积压，实际过期时间可能大于设定值。
五、队列满载与消费者拒绝场景
-
队列满载触发条件
当队列通过x-max-length设置容量上限，且新消息导致队列超限时，最早进入队列的消息会被移除并成为死信。 -
消费者拒绝消息的场景
- 消息内容无法解析（如JSON格式错误）。
- 业务逻辑校验失败（如库存不足、用户权限不符）。
- 系统暂时不可用（需设置重试机制而非重新入队）。
六、总结与建议
- 死信队列的应用：适用于需要兜底处理的场景，如订单超时、异常消息归档。
- 延迟队列选择：优先使用Delayed Exchange插件实现精准延迟；若环境限制，可通过TTL+死信交换机模拟。
- TTL设置注意事项：避免同时设置队列和消息TTL导致混淆，建议根据业务需求选择单一方式。
Comments NOTHING