下面是去掉所有 “###” 之后的《一文讲透 RabbitMQ 消息队列中的拒绝机制》中文版，结构更简洁，适合直接发布。

一文讲透 RabbitMQ 消息队列中的拒绝机制

在 RabbitMQ 中，消息拒绝是确保系统稳定性、处理异常消息（Poison Message）、控制重试策略的关键机制。本篇文章将从原理、API、DLX、重试机制到最佳实践，全面讲透 RabbitMQ 的拒绝机制。

一、什么是消息拒绝？

消息拒绝指的是：
消费者明确告诉 RabbitMQ：这条消息我无法处理，不要算成功。

当消费者拒绝消息后，RabbitMQ 会根据拒绝方式与队列配置决定消息去向，例如：重新入队、丢弃或进入死信队列。

二、RabbitMQ 的两种拒绝方式

1. basic.reject

这是最早出现的拒绝方式，一次只能拒绝一条消息：

channel.basicReject(deliveryTag, requeue);

• requeue = true：消息重新入队
• requeue = false：消息丢弃或进入死信队列

适用于简单场景。

2. basic.nack

更强大、功能更丰富：

channel.basicNack(deliveryTag, multiple, requeue);

• multiple 可批量拒绝多条消息
• requeue 用法相同

生产环境推荐使用 basic.nack。

三、拒绝消息后的行为

1. requeue = true（重新入队）

消息被放回原队列的队头。

优点：

• 可用于短暂性错误的自动重试

缺点：

• 可能产生无限重试
• 毒消息会阻塞整个队列

2. requeue = false（不重新入队）

消息被从队列移除，但是否丢弃取决于 DLX 配置：

• 队列配置了 DLX → 进入死信队列
• 未配置 → 直接丢弃

这是处理毒消息的正确姿势。

四、DLX（死信交换机）处理拒绝消息

DLX 用来接收以下消息：

• 被拒绝（requeue=false）
• 过期（TTL）
• 队列满导致丢弃
• 投递失败

常见配置：

x-dead-letter-exchange: dlx-exchange
x-dead-letter-routing-key: dlx-key

DLX 让失败消息得以保存、排查、重试。

五、Ack 与 Reject 的对比

六、拒绝机制的典型场景

场景 1：临时错误 → 再试一次

如数据库断开：

channel.basicNack(deliveryTag, false, true);

场景 2：毒消息 → 禁止重试

如数据格式永远无法处理：

channel.basicReject(deliveryTag, false);

场景 3：把失败消息送入死信队列

channel.basicNack(deliveryTag, false, false);

适用于分析或补偿处理。

场景 4：可控的重试机制（最佳实践）

典型流程：

主队列 → 拒绝 → DLX → 延迟队列 → 回到主队列

可以实现：

• 延迟重试（5s/30s/1m）
• 限定最大重试次数
• 最终失败队列隔离保存

七、拒绝机制最佳实践

✔ 使用手动 Ack 模式：

channel.basicConsume(queue, false, consumer);

✔ 毒消息不要重试，直接死信化

✔ 更多使用 basic.nack

✔ 使用 DLX + 延迟队列构建优雅重试机制

✔ 记录日志，便于排查异常数据

八、总结

RabbitMQ 的消息拒绝机制以 basic.reject 和 basic.nack 为核心。通过 requeue 参数可以控制消息是否重试。而搭配 DLX 可以实现更安全、更灵活的错误处理与重试策略。

合理使用拒绝机制可以避免系统被毒消息卡死，同时保障消息可靠可追踪。