转载

Java后端服务接口幂等常见处理方案

在编程中,一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数,或幂等方法,是指可以使用相同参数重复执行,并能获得相同结果的函数。 用通俗的话讲:就是针对一个操作,不管做多少次,产生效果或返回的结果都是一样的。

2.哪些常见的业务存在幂等问题?

在我们的业务开发过程中如果对幂等问题处理的不当,会造成脏数据,甚至造成极大损失。结合我自己这几年所接触的业务总结了常见的幂等场景分享给大家。

  • 表单提交业务
  • 第三方支付/退款业务
  • MQ相关业务
  • 抢占类业务

3.具体解决方案

3.1表单提交类

表单提交业务类型包括客户端界面的表单实体提交,修改按钮等设计增加修改数据的功能。对此业务类型前后端开发人员都需要进行幂等处理。

  • 按钮在没有新的编辑情况下置灰,不允许重复点击
  • 请求定时器限制
  • 后端接口限流控制
  • 数据库UK(唯一索引)限制
  • Token令牌的方式,取得令牌则操作实际业务,否则返回

3.2订单支付类

支付相关业务幂等的处理十分重要,比如重复的下单,三方接口的回调这些都会造成幂等问题。

  • 订单生成采用全局唯一ID方案,然后结合数据库唯一索引保证订单的唯一性,并且后续所有业务都需要此订单号做逻辑处理。
  • 微信/支付宝回调因网络原因可能导致幂等问题,可以采用业务订单号结合Redis或者结合三方返回的交易单号做验重处理,处理过的就不会再次处理。
  • 因网络原因极低概率会发生并发消费问题,回调逻辑中可以采用同步锁控制。
  • 部分业务也可以使用版本号的方式。

3.2MQ消息幂等类

MQ作为异步解耦的中间件,我们业务开发经常使用,比如用它来处理异步逻辑。但是MQ的生产者和消费者同样存在幂等问题,即重复消息,重复消费等问题。

  • producer(生产者)防止重复消息可以采用上文的验重处理,或者结合实际业务采用同步发送方案,避免了重复消息和消息丢失问题。
  • consumer(消费者)防止重复消费可以采用验重机制,根据消息的唯一标识(比如订单号)判断消息的消费状态。

3.3抢占类

并发场景的幂等的问题极易发生,而这类场景的幂等处理也不尽相同,因为都要考虑到效率问题和一致性问题,如果数据一致性要求不算太高的业务场景可以使用验重处理。如果数据一致性要求非常严格,可以采用锁机制,比如乐观锁和悲观锁的处理方案并且结合常规验重手段处理。如果是分布式集群环境则需要使用分布式锁进行处理。

原文  https://juejin.im/post/5f12b6e26fb9a07eba0c7d02
正文到此结束
Loading...