前言

最近上班比较忙，一直没来写日记。趁周末来记录一下最近遇到的一个奇葩问题。

场景：线上出现bug导致 2025.12.27 - 2025.12.29号的MQ消息处理失败了。我在29号晚上将代码修复后，新的消息可以正常处理了。所以需要将这两天的MQ的消息重新处理一下。30号我写了一个task,将这两天的消息重新发给MQ，让消费者重新处理。我观察了一下27号的消息处理成功后，就没放在心上。结果消费者一直在重复消费27号的消息。

问题

问题1: 消费记录没有报错异常，为什么会重复消费
问题2: 为什么只重复消费27号的消息，之后的消息去哪了？
问题3: 1.4号我将重复消费的消息id 发给阿里那边工作人员，阿里告诉我这条30号发送的消息，已经投递了17次了，并且全部没有ACK，导致这条消息进了死信队列，并删除了。哪为什么我在1.4号还能收到这条消息的消费记录？
阿里回复

日志中确实显示今天又收到了一次消费信息
问题4: 阿里说收到了1.4号发的消息，同样的也是投递了17次无响应被删除了，但是我并没有收到1.4号的消息。那么这些消息去哪了？
除了27号的消息，其他消息都投递次数过多被删除，但日志中完全搜不到消费记录

问题原因

在原本的消费者代码中收到消息会直接去执行业务逻辑，有些消息处理的快，有些处理很慢（五六小时）。

问题1: 消费记录没有报错异常，为什么会重复消费
因为超时了。MQ服务端会将消息投放队列中，默认一次50个。默认一定时间如果无应答则会重新投放到队列中。假设消费者是1个线程去处理。则如果第一个消息就超时很久很久，导致后面的消息还没处理，MQ服务端就认为这些消息已经全部超时了。会重新投递一次到队列中。如果第一个消息没超时，第二条消息超时了，那么剩下 48条数据，就没有处理，就已经全部超时了
问题2，3，4

这些消息并没有丢，而是阻塞住了。为什么一直在重复消费27号的？因为27号的消息，是我最先发出去的，但是因为有些消息处理很久，其实没有报错，处理完成后才会ACK，但这时候已经超时了。假设第一条消息就处理很久导致这一批没有处理的消息也超时了。MQ服务端就会重新投递一次。结果第一次投递的消息都没处理完。就导致第二次投递的消息完全超时了。结果就又投递了第三次，后面就是一直有消息超时，MQ服务端就认为前面投递的几次全超时了，就会投递下一次。最多投递17次。
消费者的表现就是：刚处理完这一批50个消息，下一批还是这50个消息，下下一批还是这50个消息。下下下一批依旧是这50个消息。直到处理这50个消息处理17次，才会真正处理新的下一批消息，这也会导致新的下一批消息也在超时，重新投递。
这也就导致，阿里那边可看到的是消息已经投递次数过多，被删除了。但是我这边还在消费的情况。阿里那边之前还开过钉钉会议。我记得他们说默认十分钟无应答就认为超时，会重新投递。

问题解决

不采用同步消费的方案。而是消费者收到消息后，将消息存入消息表。然后直接ACK。用定时任务去处理消息表中的消息，处理完成后改状态。一开始是单线程去处理的，结果处理速度赶不上进消息的速度，然后那个业务还给领导打我小报告！我真服啦。怎么这么烦人。后面又给他改成了采用线程池去处理加快了速度。好啦。问题结束！最近真的超想跳槽。干到过年就辞职吧