基于幂等重试分布式消息一致性保障方案.pdfVIP

所有的MQ自己都会确保说让你消费到这条数据，而且尤其是配合我们打开了手动ack的机

制

那么如果678出了问题呢，其实678出了问题啊，因为MQ没有得到ACK，MQ都会自己不

断的重新投递的，多次投递这样子

然后9出了问题，其实数据是对的，只不过可靠消息服务里的消息状态不对而已

我们可以去考虑说将6789四个步骤如果有失败的话，都不要完全依赖MQ的重投机制，我

们可以依赖于自己设计的可靠消息服务的重投机制来做保证其处理

所以6789出问题，其实消息的状态都是“已发送”，如果是8和9出问题，那么下游数据库

的操作已经执行成功了

（1）可以开一个线程，专门“已发送”的消息，如果超过了10分钟，那么就需要

判定为超时了

（2）这个时候也是需要可靠消息服务再次重新投递消息给到MQ，让下游服务再次去消费

（3）下游服务的接口一定要保证幂等性，数据库操作只能成功的执行一次

如果是6和7出问题，那么下游服务的本地数据库操作还没执行，此时重新投递了一条消

息，那么正常情况下，就会执行数据库操作，反过来可靠消息服务变更消息状态为“已

完成”，但是如果是8和9出问题，那么实际上此时下游服务的本地数据库操作已经执行成

功了，只不过消息状态还是“已发送”而已

所以此时如果你的可靠消息服务再次投递消息，导致下游服务再次执行了数据库操作，