消息重复和幂等问题是很常见的问题，这俩问题基本可以放在一起。 既然是消费消息，那肯定要考虑考虑会不会重复消费？能不能避免重复消费？或者重复消费了也别造成系统异常可以吗？这个是MQ领域的基本问题，其实本质上还是问你使用消息队列如何保证幂等性，这个是你架构里要考虑的一个问题即实际生产上的系统设计问题。
一 什么情况会导致消息被重复消费呢?
这里举个业务栗子 生产者 → MQ → 消费者 当我们生产者生产数据到MQ中后,消费者会从MQ中顺序取数据,当这些消息被消费后会告诉MQ我现在消费到哪里了,如果消费者服务器宕机了,再次消费时候会消费之前记录的下一条消息.但是有时候我们已经消费到哪里的消息还没提交就宕机了,那么可能重启后就还会消费原来的数据.
kafka重读消费栗子
其实重复消费不可怕，可怕的是没考虑到重复消费之后，怎么保证幂等性。
再举个重复消费的栗子。 假设有个系统，消费一条往数据库里插入一条，要是你一个消息重复两次，你就插入了两条，这数据就错了. 但是你要是消费到第二次的时候，自己判断一下已经消费过了，直接扔了，就只保留了一条数据.一条数据重复出现两次，数据库里就只有一条数据，这就保证了系统的幂等性
幂等性:通俗点说就是一个数据或者一个请求，重复来多次，都可以确保对应的数据是不会改变的，不能出错。
二 如何保证消息不被重复消费或者说保证消息的幂等性?
如何保证MQ的消费是幂等性的，需要结合具体的业务来看
大致思路就是判重:
（1）比如你拿个数据要写库，你先根据主键查一下，如果这数据都有了，你就别插入了，update一下
（2）比如你是写redis，那没问题了，每次都是set，天然幂等性
（3）比如你不是上面两个场景，那做的稍微复杂一点。 让生产者发送每条数据的时候，里面加一个全局唯一的id，类似订单id之类的东西，然后你这里消费到了之后，先根据这个id去比如redis里查一下，之前消费过吗？如果没有消费过，就去消费处理，然后这个id写redis。如果消费过了，就别处理了，保证不重复处理相同的消息即可。
再比如基于数据库的设置唯一键来保证重复数据不会重复插入多条. 就是拿到数据的时候，每次重启可能会有重复，因为kafka消费者还没来得及提交offset，重复数据拿到了以后我们插入的时候，因为有唯一键约束了，所以重复数据只会插入报错，不会导致数据库中出现脏数据
