前言

消息重复消费是各个MQ都会发生的常见问题之一，在一些比较敏感的场景下，重复消费会造成比较严重的后果，比如重复扣款等。

那么在什么情况下会发生RocketMQ的消息重复消费呢？

1. 当系统的调用链路比较长的时候，比如系统A调用系统B，系统B再把消息发送到RocketMQ中，在系统A调用系统B的时候，如果系统B处理成功，但是迟迟没有将调用成功的结果返回给系统A的时候，系统A就会尝试重新发起请求给系统B，造成系统B重复处理，发起多条消息给RocketMQ造成重复消费。
2. 在系统B发送消息给RocketMQ的时候，也有可能会发生和上面一样的问题，消息发送超时，结果系统B重试，导致RocketMQ接收到了重复的消息。
3. 当RocketMQ成功接收到消息，并将消息交给消费者处理，如果消费者消费完成后还没来得及提交offset给RocketMQ，自己宕机或者重启了，那么RocketMQ没有接收到offset，就会认为消费失败了，会重发消息给消费者再次消费。

消息重复消费的场景大概可以分为生产者端重复消费和消费者端重复消费，那么如何来解决消息的重复消费呢？

答案是通过幂等性来保证，只要保证重复消费的消息不对结果产生影响，就完美地解决这个问题。

• 在生产者端要保证幂等性的话，大概可以使用以下两种方式：

  1. RocketMQ支持消息查询的功能，只要去RocketMQ查询一下是否已经发送过该条消息就可以了，不存在则发送，存在则不发送
  2. 引入redis，在发送消息到RocketMQ成功之后，向redis中插入一条数据，如果发生重试，则先去redis中查询一下该条消息是否已经发送过了，存在的话就不重复发送消息了

• 生产者的这两种幂等性方案都可以实现，但是都存在一定的缺陷

  • 方案①，RocketMQ消息查询的性能不是特别好，如果是在高并发的场景下，每条消息在发送到RocketMQ时都去查询一下，可能会影响接口的性能
  • 方案②，在一些极端的场景下，redis也无法保证消息发送成功之后，就一定能写入redis成功，比如写入消息成功而redis此时宕机，那么再次查询redis判断消息是否已经发送过，是无法得到正确结果的

既然在生产者做幂等性的方案都不是特别靠谱，那就再在消费者端来做吧

• 消息的消费，最后都对应的是数据库的操作，只要在消息消费的时候，判断一下数据库中是否已经消费过了这条消息，就可以保证幂等性了，例如使用唯一索引，保证一条消息只被消费一次。
  

• 消息重复消费是一个非常常见的问题，在很多系统调用频繁的场景下，都可能会出现超时重试的情况，还有就是系统频繁迭代，经常重启系统更新的场景，也会出现消息重复消费。

• 生产者端发送重复的消息到RocketMQ中其实问题不大，消息只是在RocketMQ中重复了，并没有影响到系统的数据，我们只需要在最后修改数据库的时候，保证好幂等性即可。