支付系统|接口服务中的幂等性设计的理解,详细分析幂等性的几种实现方法


支付系统|接口服务中的幂等性设计的理解,详细分析幂等性的几种实现方法
文章图片
支付系统|接口服务中的幂等性设计的理解,详细分析幂等性的几种实现方法
深入理解Java中的幂等性

  • 什么是幂等性
  • 幂等性的使用场景
  • 幂等和防重
  • 保证幂等性的情况
  • 设计幂等性服务
    • 保证幂等策略
    • 防重复提交策略
      • 乐观锁
      • 防重表
      • 分布式锁
      • token令牌
      • 支付缓冲区
什么是幂等性
  • 幂等性定义:一次和多次请求某一个资源对于资源本身应该具有同样的结果任意多次执行对资源本身所产生的影响均与一次执行的影响相同
  • 幂等性定义的几个重点:幂等不仅仅只是一次或者多次请求对资源没有副作用比如查询数据库操作没有增删改无论多少次操作对数据库都没有任何影响幂等还包括第一次请求的时候对资源产生了副作用但是以后的多次请求都不会再对资源产生副作用幂等关注的是以后多次请求是否对资源产生副作用并不关注结果网络超时等问题不是幂等的讨论范围
  • 幂等性是系统服务对外一种承诺而不是实现
  • 承诺只要调用接口成功外部多次调用对系统的影响是一致的
  • 声明为幂等的服务会认为外部调用失败是常态并且失败后必然会有重试

幂等性的使用场景
  • 业务开发中经常遇到重复提交的情况:由于网络问题无法收到请求结果而重新发起请求前端的操作抖动而造成的重复提交的情况
  • 在交易系统中支付系统这种重复提交造成的问题尤为明显:用户在APP上连续点击多次提交订单后台应该只产生一个订单向支付系统发起请求由于网络问题或者系统Bug问题导致重发支付系统应该只做一次扣除操作
  • 声明幂等的服务认为外部调用者会存在多次调用的情况为了防止外部多次调用对系统的数据状态发生多次改变需要将服务设计为幂等
幂等和防重
  • 重复提交的情况和服务等的初衷是不同的
    • 重复提交是在第一次请求已经成功的情况下人为地进行多次操作导致不满足幂等要求的服务员多次改变状态
    • 幂等更多使用的情况是第一次请求因为某些情况不如超时而导致不知道结果或者请求失败的异常情况下发起多次请求
  • 幂等的目的是请求多次确认第一次请求成功不会因为多次请求而出现多次的状态变化

保证幂等性的情况
  • 在SQL中有以下三种场景只有第三种场景需要保证幂等性:
    • SELECT col1 FROM tab1 WHERE col2=2:无论执行多少次都不会改变状态是天然的幂等
    • UPDATE tab1 SET col1=1 WHERE col2=2:无论执行成功多少次状态都是一致的也是幂等操作
    • UPDATE tab1 SET col1=col1+1 WHERE col2=2: 每次执行的结果都会发生变化这种不是幂等的要采取策略保证幂等性
设计幂等性服务
  • 幂等使得客户端逻辑处理很简单但是服务端逻辑会很复杂
  • 满足幂等性服务需要包含两点逻辑:
    • 首先去查询上一次的执行状态如果没有则认为是第一次请求
    • 在服务改变状态的业务逻辑前保证防重复提交的逻辑
保证幂等策略
  • 幂等需要通过唯一的业务单号来保证:相同的业务单号认为是同一业务使用唯一的业务单号确保:后面多次相同业务单号的处理逻辑和执行效果是一致的
  • 幂等实现示例-支付:先查询订单是否支付过如果已经支付过返回支付成功如果没有支付则进行支付流程修改订单的状态为已支付
防重复提交策略
  • 在保证幂等的策略中执行是分两步执行的后面一步依赖上面一步的查询结果这样就无法保证原子性
  • 无法保证原子性在高并发的情况下会存在问题:第二次请求在第一次请求的下一步订单状态没有修改为\"已支付状态\"时进行为了解决这个问题:将查询和变更状态操作加锁并将并行操作改为串行执行
乐观锁