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

  • 如果只是更新已有的数据没有必要对业务进行加锁
  • 设计表结构时使用乐观锁一般通过version来实现乐观锁:保证执行效率保证幂等
  • UPDATE tab1  SET\tcol1=1version=version+1
     WHERE\tversion=#version#

    由于ABA问题会导致乐观锁存在失效的情况只要保证version值自增就不会出现ABA的问题
    防重表
    • 使用orderNo作为去重表中的唯一索引每次请求都根据订单号orderNo向去重表中插入一条数据:第一次请求查询订单支付状态:订单没有支付进行支付操作无论成功与否执行完成之后更新订单的状态为成功或失败删除去重表中的数据后续订单因为表中的唯一索引插入失败返回操作失败直到第一次请求完成(成功或者失败)
    • 防重表的作用是实现加锁的功能
    分布式锁
    • 可以使用Redis分布式锁代替防重表的功能
    • 示例:订单发起支付请求支付系统会去Redis缓存中查询是否存在该订单Key如果不存在向Redis中增加Key为订单号查询订单支付是否已经支付如果没有则进行支付支付完成后删除该订单的Key
    • 通过Redis实现分布式锁只有这次订单请求完成下次请求才会进来
    • 对比去重表Redis分布式锁将放并发做在缓存中效率更高
    • 同一时间只能完成一次支付请求
    token令牌
    • token令牌分为两个阶段:申请token阶段:在进入到提交订单页面之前需要订单系统根据用户信息向支付系统发起一次申请token的请求支付系统将token保存到Redis缓存中给支付阶段使用支付阶段:订单系统获取到申请的token发起支付请求支付系统检查Redis是否存在该token如果存在表示第一次发起支付请求删除缓存中的token开始支付逻辑处理如果缓存中不存在表示非法请求
    支付缓冲区
    • 支付缓冲区:将订单的支付请求都快速地接收下来是一个快速接收请求的缓冲管道使用异步任务处理管道中的数据过滤调掉重复的待支付的数据
    • 优点:同步转异步高吞吐
    • 缺点:无法及时返回支付结果需要后续监听支付结果的异步返回
    幂等的不足:- 幂等是为了简化客户端逻辑但是增加了服务提供者的逻辑和成本- 幂等的使用需要根据具体场景具体分析- 增加了额外控制幂等的业务逻辑复杂了业务功能- 将并行的功能转化为串行降低了执行效率

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