RabbitMQ异步请求处理过慢是否会导致重复执行？

答案是肯定的，这种情况完全有可能发生，核心原因和RabbitMQ的消息确认机制、超时判定逻辑直接相关，下面具体拆解场景和原因：

触发重复执行的关键场景 #

• 消费者心跳超时：RabbitMQ通过心跳机制判断消费者是否存活。如果你的消息处理时间太长，超过了配置的心跳间隔（默认一般是60秒，也可能被设置得更短），RabbitMQ会认为这个消费者已经断开连接，将未确认的消息重新投递给其他可用的消费者（甚至单消费者部署时，重启后也会重新接收这条消息）。这就会出现原消费者还在处理消息，新的消费者已经开始执行同一条消息的情况，和你描述的时间线完全吻合。
• 手动确认模式下的确认延迟：如果你的消费者使用手动消息确认（basic.ack），但处理消息的时间超过了RabbitMQ的相关超时阈值（比如连接超时、通道超时），或者消费者在处理过程中卡住没及时发送确认，RabbitMQ会把这条消息标记为未确认并重新入队分配。
• prefetch count设置不合理：如果一次性拉取了过多消息到消费者本地（prefetch count值过大），当其中一条消息处理极慢时，RabbitMQ可能因为长时间没收到该消费者的确认信号，判定其异常，进而重新分发未确认的消息。

如何避免这类问题？ #

• 调整心跳和超时配置：根据你的消息最大处理时间，合理设置心跳间隔（比如如果单条消息最长处理1分钟，心跳间隔设为90秒），确保RabbitMQ不会误判消费者死亡。
• 优化消息确认逻辑：在手动确认模式下，务必保证消息处理完成后立即发送basic.ack，不要在处理前确认，也不要延迟确认。
• 实现幂等性处理：这是最根本的解决方案——不管消息被重复投递多少次，业务逻辑执行的结果都是一致的。比如给每条消息生成唯一ID，处理前先检查该ID是否已经被处理过，避免重复执行带来的业务问题。
• 合理设置prefetch count：根据消费者的处理能力，设置合适的预取数量，避免一次性积压过多消息在本地。

内容的提问来源于stack exchange，提问作者Avinash Kalol