开发者社区> 问答> 正文

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

MQ有可能发生重复消费,如何避免,如何做到幂等?

展开
收起
月下丶 2018-12-14 22:54:15 2640 0
2 条回答
写回答
取消 提交回答
  • 公众号「服务端思维」

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

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

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

    2019-07-17 23:21:45
    赞同 展开评论 打赏
  • 阿里云问答专家、阿里云认证云计算工程师、Java研发工程师

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

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

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

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

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

    2019-07-17 23:21:45
    赞同 展开评论 打赏
问答分类:
问答地址:
问答排行榜
最热
最新

相关电子书

更多
微信红包系统可用性设计实践 立即下载
攻克痛点:如何保证复杂微服务架构下的数据一致性 立即下载
如何实现应用的持续发布 立即下载