防重幂等

Posted 2021-11-03 练习两年半的攻城狮

前言：

在分布式系统下，服务之间相互调用，必然会存在调用失败并且进行重试的情况，在某些情况下就需要做好防重幂等。

防重和幂等是什么？

防重：避免产生重复数据

幂等：除了避免产生重复数据之外，还要求每次请求都返回一样的结果

什么情况会导致重复？

发送方发送相同的请求到服务端。

• 前端多次发送相同的请求到后端
• 超时重发导致的重复
• MQ异常导致的重复消费

如何防重？

• insert之前先select，通常情况下有效，但是在高并发情况下，也会导致重复

• 建立唯一索引，数据库兜底，防止重复添加

• 某些业务表在特定的场景下才不允许重复，不能直接建立唯一键，就可以增加一张防重表（为此类业务），将此类数据在同一事务下先insert进防重表成功，在insert业务表，假如insert进防重表失败，证明此类数据重复，就不用再处理业务表了

• 加分布式锁（针对单据来锁）：需要合理设置过期时间。不能太短，导致业务没有处理完，锁失效，防重失败；也不能不设置过期时间，解锁异常导致锁一直被占，阻塞后续处理。

什么情况要做幂等？

用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用。

例如：

• 比如用户对一笔订单发起付款，因为网络问题没有返回结果，就多次点击付款按钮，此时只能发起一笔真实的交易，生成一条交易记录。
• 分布式系统中，因为接口超时，导致的重试，第一次请求接口超时，没有获取到返回结果（有可能已经成功了），第二次重试，接收方不能直接返回失败，要根据第一次处理的结果进行返回。

怎么解决？

1. 新增数据类接口，通过防重解决。
2. 更新类接口，比如更新库存，更改状态等，通过状态，加乐观锁解决。

根据状态判断

很多业务是有状态的，比如一个订单表。有下单0、支付中1、已支付2、取消支付3等状态，

假如id=123的订单状态是0，现在要变成支付中状态。

update order set status=1 where id=123 and status=0;

第一次请求时，该订单的状态可以正常更新，sql执行结果的影响行数是1，订单状态变成了1。后面有相同的请求过来，再执行相同的sql时，由于订单状态变成了1，再用status=0作为条件，最终sql执行结果的影响行数是0，即不会真正的更新数据。但为了保证接口幂等性，接口也需要直接返回成功。

加乐观锁，在表中增加一个version字段。

在更新数据之前先查询一下数据：

select id,amount,version from user id=123;

如果数据存在，假设查到的version等于1，再使用id和version字段作为查询条件更新数据：

update user set amount=amount+100,version=version+1 where id=123 and version=1;

更新数据的同时version+1，然后判断本次update操作的影响行数，如果大于0，则说明本次更新成功，如果等于0，则说明本次更新没有让数据变更。

由于第一次请求version等于1是可以成功的，操作成功后version变成2了。这时如果并发的请求过来，再执行相同的sql：

update user set amount=amount+100,version=version+1 where id=123 and version=1;

该update操作不会真正更新数据，最终sql的执行结果影响行数是0，因为version已经变成2了，为了保证接口幂等性，接口可以直接返回成功，因为version值已经修改了，那么前面必定已经成功过一次，后面都是重复的请求。

总结

• 网络延迟问题：先发的不一定先到
• 数据库操作延迟：先到的不一定先执行完
• 不能依赖上游或下游去做防重幂等，自己本身也要把控好
• 对于外部接口，没有明确返回可重试状态的，不要轻易重试

接口服务中的幂等性设计和防重保证，详细分析幂等性设计几种实现方法

什么是幂等性

• 幂等性定义:

  • 一次和多次请求某一个资源对于资源本身应该具有同样的结果
  • 任意多次执行对资源本身所产生的影响均与一次执行的影响相同

• 幂等性定义的几个重点:

  • 幂等不仅仅只是一次或者多次请求对资源没有副作用

    • 比如,查询数据库操作,没有增删改,无论多少次操作对数据库都没有任何影响
  • 幂等还包括第一次请求的时候对资源产生了副作用,但是以后的多次请求都不会再对资源产生副作用
  • 幂等关注的是以后多次请求是否对资源产生副作用,并不关注结果
  • 网络超时等问题,不是幂等的讨论范围
• 幂等性是系统服务对外一种承诺,而不是实现
• 承诺只要调用接口成功,外部多次调用对系统的影响是一致的

• 声明为幂等的服务会认为外部调用失败是常态,并且失败后必然会有重试

  幂等性的使用场景

• 业务开发中,经常遇到重复提交的情况:

  • 由于网络问题无法收到请求结果而重新发起请求
  • 前端的操作抖动而造成的重复提交的情况

• 在交易系统中,支付系统这种重复提交造成的问题尤为明显:

  • 用户在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: 每次执行的结果都会发生变化,这种不是幂等的,要采取策略保证幂等性

    设计幂等性服务

• 幂等使得客户端逻辑处理很简单,但是服务端逻辑会很复杂

• 满足幂等性服务需要包含两点逻辑:

  • 首先去查询上一次的执行状态,如果没有则认为是第一次请求

  • 在服务改变状态的业务逻辑前保证防重复提交的逻辑

    保证幂等策略

• 幂等需要通过唯一的业务单号来保证:

  • 相同的业务单号,认为是同一业务
  • 使用唯一的业务单号确保:后面多次相同业务单号的处理逻辑和执行效果是一致的

• 幂等实现示例-支付:

  • 先查询订单是否支付过
  • 如果已经支付过,返回支付成功

  • 如果没有支付,则进行支付流程,修改订单的状态为已支付

    防重复提交策略

• 在保证幂等的策略中,执行是分两步执行的,后面一步依赖上面一步的查询结果,这样就无法保证原子性

• 无法保证原子性在高并发的情况下会存在问题:

  • 第二次请求在第一次请求的下一步订单状态没有修改为"已支付状态"时进行

  • 为了解决这个问题 :将查询和变更状态操作加锁,并将并行操作改为串行执行

    乐观锁

• 如果只是更新已有的数据,没有必要对业务进行加锁

• 设计表结构时使用乐观锁,一般通过version来实现乐观锁:

  • 保证执行效率

  • 保证幂等

    UPDATE tab1
    SET    col1=1,version=version+1
    WHERE    version=#version# 

    由于ABA问题会导致乐观锁存在失效的情况,只要保证version值自增就不会出现ABA的问题

    防重表

• 使用orderNo作为去重表中的唯一索引,每次请求都根据订单号orderNo向去重表中插入一条数据:

  • 第一次请求查询订单支付状态:

    • 订单没有支付
    • 进行支付操作
    • 无论成功与否,执行完成之后更新订单的状态为成功或失败,删除去重表中的数据
    • 后续订单因为表中的唯一索引插入失败,返回操作失败,直到第一次请求完成(成功或者失败)

• 防重表的作用是实现加锁的功能

  分布式锁

• 可以使用Redis分布式锁代替防重表的功能

• 示例:

  • 订单发起支付请求
  • 支付系统会去Redis缓存中查询是否存在该订单Key
  • 如果不存在,向Redis中增加Key为订单号
  • 查询订单支付是否已经支付
  • 如果没有则进行支付,支付完成后删除该订单的Key
• 通过Redis实现分布式锁,只有这次订单请求完成,下次请求才会进来
• 对比去重表,Redis分布式锁将放并发做在缓存中,效率更高

• 同一时间只能完成一次支付请求

  token令牌

• token令牌分为两个阶段:

  • 申请token阶段:

    • 在进入到提交订单页面之前,需要订单系统根据用户信息向支付系统发起一次申请token的请求
    • 支付系统将token保存到Redis缓存中,给支付阶段使用

  • 支付阶段:

    • 订单系统获取到申请的token, 发起支付请求,

    • 支付系统检查Redis是否存在该token

      • 如果存在,表示第一次发起支付请求,删除缓存中的token开始支付逻辑处理

      • 如果缓存中不存在,表示非法请求

        支付缓冲区

• 支付缓冲区:

  • 将订单的支付请求都快速地接收下来,是一个快速接收请求的缓冲管道
  • 使用异步任务处理管道中的数据,过滤调掉重复的待支付的数据
• 优点: 同步转异步,高吞吐

• 缺点: 无法及时返回支付结果,需要后续监听支付结果的异步返回

• 幂等是为了简化客户端逻辑,但是增加了服务提供者的逻辑和成本
• 幂等的使用需要根据具体场景具体分析
• 增加了额外控制幂等的业务逻辑,复杂了业务功能

• 将并行的功能转化为串行,降低了执行效率