RabbitMQ异步ACK异常咨询：重复delivery tag引发报错

首先咱们把你的场景和问题捋清楚：

你的环境与异常情况 #

环境配置 #

• 持久化的交换机与队列
• 手动ACK模式
• Spring Boot集成RabbitMQ
• SimpleMessageListenerContainer配置：并发消费者10个，最大消费者50个

异常场景 #

你发送消息m1后紧接着发m2，m1处理耗时久，m2先处理完成。但两条消息的delivery tag居然都是1——m2先ACK之后，m1再ACK时直接抛出**「未知delivery tag 1」**异常。更诡异的是，生产者收到了m1的ACK确认，但RabbitMQ控制台里m1却长期处于未确认（unacked）状态。

核心疑问 #

同一队列同一通道下，能不能先ACK m2再ACK m1？而且你没法保证两条消息投递到不同队列。

问题本质：Delivery Tag的作用范围搞混了 #

首先要敲黑板：Delivery Tag的唯一性是基于「通道（Channel）」的，不是队列。你遇到的问题根本不是「同一通道下乱序ACK」的问题，而是m1和m2被分配到了不同的Channel上，巧合的是它们在各自的Channel里都是第一个被处理的消息，所以Delivery Tag都是1。

当你用m2所在的Channel去ACK它的Tag 1时，这个操作是有效的；但之后你再用同一个Tag 1去ACK m1时，这个Tag在m1所在的Channel里要么已经失效，要么根本不存在——因为m1的Tag 1只在它自己的Channel里有效，所以RabbitMQ自然会抛出「未知delivery tag」的异常。

至于为什么会分到不同Channel？因为你配置了10个并发消费者，每个消费者都会对应一个独立的Channel，RabbitMQ会把队列里的消息轮询或者按策略分发给这些不同Channel上的消费者，m1和m2刚好被分到了不同的Channel上。

关于「同一队列同一通道下乱序ACK」的结论 #

如果两条消息真的是在同一个Channel下被投递的，那完全可以先ACK m2再ACK m1——RabbitMQ完全支持同一Channel内的乱序ACK，只要你用的是该Channel对应的正确Delivery Tag就行。

但你的情况根本不是同一Channel的场景，是Channel不同导致的Tag重复冲突。

解决方案 #

针对你的场景，给你几个可行的修复方向：

1. 严格绑定消息与对应Channel的ACK操作：在Spring Boot的手动ACK逻辑里，一定要用消息回调时传入的Channel对象来执行ACK。比如用ChannelAwareMessageListener的话，直接用方法参数里的channel调用basicAck(deliveryTag, false)，绝对不要复用全局的Channel实例——每个消息的Channel都是专属的，不能乱混用。
2. 避免手动管理Delivery Tag（可选）：如果业务逻辑允许，可以考虑切换到AcknowledgeMode.AUTO自动ACK模式，但如果你的场景必须手动控制ACK时机，这条就跳过。
3. 明确并发消费者的Channel特性：既然用了并发消费者，就要清楚每个消费者对应独立Channel的特性，在代码里绝对不要把不同消息的Delivery Tag和Channel搞混。

额外异常的解释 #

你提到的「生产者收到m1的ACK，但控制台显示m1 unacked」也很好解释：你错误地用m2的Channel去ACK了Tag 1，这个操作在m2的Channel里是有效的（因为m2的Tag 1确实存在且已处理），所以RabbitMQ给生产者返回了ACK确认；但m1所在的Channel从来没收到过针对它的Tag 1的ACK，所以控制台里m1一直处于unacked状态，直到这个消费者断开连接，RabbitMQ才会把m1重新放回队列。

内容的提问来源于stack exchange，提问作者Aditya Ekbote