记一次rabbitmq因double ack导致的报错：method channel.close (reply-code=406, reply-text=PRECONDITION_FAILED ...

场景：

搭建了一套rabbitmq的高可用服务，生产端和消费端都能正常使用，但在日志中竟然出现了一条Error信息，不能忍啊！Error信息如下：

2020-05-13 00:19:13.324 ERROR 12499 --- [68.152.119:5672] o.s.a.r.c.CachingConnectionFactory       : Channel shutdown: channel error; protocol method: #method<channel.close>(reply-code=406, reply-text=PRECONDITION_FAILED - unknown delivery tag 1, class-id=60, method-id=80)

简直有点莫名其妙，报错但不影响使用。检查了好几遍配置，什么开启手工签收（手动ack）机制啥的，都木得问题啊。

于是，按照报错信息搜索，好多解决方案就是贴配置信息，连报错的原因都木得，水的一批的博客比比皆是，关键还互相抄袭。最终在一个挺久的帖子上看到了线索：可能是double ack。考虑到之前就出现过代码中的配置覆盖了配置文件中配置的情况，所以就从确认机制的配置着手。

 按照double ack思考，开启了手动ack，竟然还会出现double ack。那必定是配置被覆盖了。于是rabbitmq的配置类被我逐行审查，终于代码漏出了马脚。

原因：

在配置序列化json消息转换器的时候出现了覆盖。所以配置文件中的手动ack配置被SimpleRabbitListenerContainerFactory中的配置所覆盖，而rabbitmq默认使用的auto ack。当然是用默认自动ack并不意味这channel.basicAck(deliveryTag, false)就不能用了。于是乎出现：消息被消费后自动确认后，又执行到手动channel.basicAck(deliveryTag, false)，导致最终出现了两次ack。所以就有了#method<channel.close>(reply-code=406, reply-text=PRECONDITION_FAILED - unknown delivery tag 1, class-id=60, method-id=80)的报错。

配置类和配置文件部分截图如下：

解决方案：

在SimpleRabbitListenerContainerFactory的配置中，再次设置消息确认机制为手动ack，即可解决此类报错。