消息队列-如果保证消息的重复消费？怎么保证消息队列消费的幂等性？

面试连环炮

• 你用过消息队列么？
• 说说你们项目里是怎么用消息队列的？
  • 我们有一个订单系统，订单系统会每次下一个新订单的时候，就会发送一条消息到ActiveMQ里面去，后台有一个库存系统，负责获取消息，然后更新库存。
• 为什么使用消息队列？
  • 你的订单系统不发送消息到MQ，而是直接调用库存系统的一个接口，然后直接调用成功了，库存也更新了，那就不需要使用消息队列了呀
  • 使用消息队列的主要作用是：异步、解耦、削峰
• 消息队列都有什么优缺点？
• Kafka、activeMQ、RibbitMQ、RocketMQ都有什么优缺点？
• 如何保证消息队列的高可用？
• 如何保证消息不被重复消费？如何保证消息消费时的幂等性？
• 如何保证消息的可靠性传输，要是消息丢失了怎么办？
• 如何保证消息的顺序性？
• 如何解决消息队列的延时以及过期失效问题？消息队列满了以后该怎么处理？有几百万消息持续积压几小时，说说怎么解决？
• 如果让你写一个消息队列，该如何进行架构设计，说一下你的思路？

面试题

如何保证消息的重复消费？如何保证消息消费的幂等性？

剖析

其实这是一个常见的问题，既然是消费消息，那肯定是要考虑会不会重复消费？能不能避免重复消费？或者重复消费了也别造成系统异常可以吗？关于消息重复消费的问题，其实本质上就是问你使用消息队列如何保证幂等性，这个是你架构中要考虑的问题。

首先是比尔RabbitMQ、RocketMQ、Kafka都会出现消息重复消费的问题，因为这个问题通常不是MQ自己保证的，而是保证消息的不丢失，我们首先从Kafka上来说：

kafka实际上有个offset的概念，就是每个消息写进去，都有一个offset，代表他的序号，然后consumer消费了数据之后，每隔一段时间，会把自己消费过的消息offset提交一下，代表我已经消费过了，下次我要是重启啥的，你就让我从上次消费到的offset来继续消费。

但是凡事总有以外，比如我们之前生产经常遇到的，就是你有时候重启系统，看你怎么重启，如果碰到着急的，直接kill杀死进程，然后重启，这就会导师consumer有些消息处理了没来得及提交offset，然后重启后，就会造成少数消息重复消费的问题。

重复消费不可怕，重要的是有没有考虑过重复消费之后，怎么保证幂等性？

例如：有个系统，消费一条数据往数据库插入一条，要是消息重复消费了两次，那么就插入两条数据了，这个数据也就出错了。

消费者如果在准备提交offset，但是还没有提交的时候，消费者进程被重启，那么此时已经消费过数据的offset并没有提交，kafka也就不知道你已经消费了，那么消费者再次上线进行消费的时候，会把已经消费的数据，重新在传递过来，这就是消息重复消费的问题。

幂等性是什么？

通俗点说：幂等性就是一个数据，或者一个请求，给你执行多次，得保证对应的数据不会改变，并且不能出错，这就是幂等性。

怎么保证消息队列消费的幂等性？

一条数据重复出现两次，但是数据库里只有一条数据，这就保证了系统的幂等性。

解决思路

• 比如数据要写库，首先根据主键查一下，如果这个数据已经有了，那就别插入了，执行update即可
• 如果用的是redis，那就没问题了，因为每次都是set操作，天然的幂等性
• 如果不是上面的两个场景，那就做的稍微复杂一点，需要让生产者发送每条消息的时候，需要加一个全局唯一的id，类似于订单id之后的东西，然后你这里消费到了之后，先根据这个id去redis中查找，之前消费过了么，如果没有消费过，那就进行处理，然后把这个id写入到redis中，如果消费过了，那就别处理了，保证别重复消费相同的消息即可。
• 还有比如基于数据库唯一键来保证重复数据不会重复插入多条，我们之前线上系统就有这个问题，就是拿到数据的时候，每次重启可能会重复，因为Kafka消费者还没来得及提交offset，重复数据拿到了以后，我们进行插入的时候，因为有了唯一键约束了，所以重复数据只会插入报错，不会导致数据库中出现脏数据。