[@小川游鱼][¥20]MQ有可能发生重复消费，如何避免，如何做到幂等？

我们探讨过幂等机制的实现方案，今天我们再来探讨下分布式锁是不是控制并发幂等的方式？ 可能由于客户端的重复提交产生多份相同的数据，也可能因为服务端的重试机制产生多次提交。此时，单单通过防重机制是不够的，还需要服务端的幂等机制保证唯一性。幂等机制的核心是保证资源唯一性，例如客户端重复提交或服务端的多次重试只会产生一份结果。支付场景、退款场景，涉及金钱的交易不能出现多次扣款等问题。事实上，查询接口用于获取资源，因为它只是查询数据而不会影响到资源的变化，因此不管调用多少次接口，资源都不会改变，所以是它是幂等的。而新增接口是非幂等的，因为调用接口多次，它都将会产生资源的变化。因此，我们需要在出现重复提交时进行幂等处理。

注意的是，为了避免并发场景，我们可以通过锁机制，例如悲观锁与乐观锁保证数据的唯一性。这里，分布式锁是一种经常使用的方案，它通常情况下是一种悲观锁的实现。但是，很多人经常把悲观锁、乐观锁、分布式锁当作幂等机制的解决方案，这个是不正确的。并发控制只是保证临界区资源的安全，不出现脏数据，如果并发控制，多次提交是合法的，只是业务方面不合法，所以做幂等控制 。（感谢，【零度】诠释）

因此，通过分布式锁不是控制并发幂等的方式，需要在提交记录的时候通过幂等机制保证数据的唯一性，确保不论如何设置超时时间，都不会出现幂等控制的问题。

如何保证MQ的消费是幂等性的，需要结合具体的业务来看 ：

　　比如你拿个数据要写库，你先根据主键查一下，如果这数据都有了，你就别插入了，update一下好吧；

　　比如你是写redis，那没问题了，反正每次都是set，天然幂等性；

　　比如你不是上面两个场景，那做的稍微复杂一点，你需要让生产者发送每条数据的时候，里面加一个全局唯一的id，类似订单id之类的东西，然后你这里消费到了之后，先根据这个id去比如redis里查一下，之前消费过吗？如果没有消费过，你就处理，然后这个id写redis。如果消费过了，那你就别处理了，保证别重复处理相同的消息即可；

　　还有比如基于数据库的唯一键来保证重复数据不会重复插入多条，拿到数据的时候，每次重启可能会有重复，因为kafka消费者还没来得及提交offset，重复数据拿到了以后我们插入的时候，因为有唯一键约束了，所以重复数据只会插入报错，不会导致数据库中出现脏数据 。