接口服务中的幂等性设计和防重保证,详细分析幂等性的实现方法
什么是幂等性
幂等性定义:
一次和多次请求某一个资源对于资源本身应该具有同样的结果
任意多次执行对资源本身所产生的影响均与一次执行的影响相同
幂等性定义的几个重点:
幂等不仅仅只是一次或者多次请求对资源没有副作用
比如,查询数据库操作,没有增删改,无论多少次操作对数据库都没有任何影响
幂等还包括第一次请求的时候对资源产生了副作用,但是以后的多次请求都不会再对资源产生副作用
幂等关注的是以后多次请求是否对资源产生副作用,并不关注结果
网络超时等问题,不是幂等的讨论范围
幂等性是系统服务对外一种承诺,而不是实现
承诺只要调用接口成功,外部多次调用对系统的影响是一致的
声明为幂等的服务会认为外部调用失败是常态,并且失败后必然会有重试
幂等性的使用场景
业务开发中,经常遇到重复提交的情况:
由于网络问题无法收到请求结果而重新发起请求
前端的操作抖动而造成的重复提交的情况
在交易系统中,支付系统这种重复提交造成的问题尤为明显:
用户在 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 来实现乐观锁:
保证执行效率
保证幂等
由于 ABA 问题会导致乐观锁存在失效的情况,只要保证 version 值自增就不会出现 ABA 的问题
防重表
使用 orderNo 作为去重表中的唯一索引,每次请求都根据订单号 orderNo 向去重表中插入一条数据:
第一次请求查询订单支付状态:
订单没有支付
进行支付操作
无论成功与否,执行完成之后更新订单的状态为成功或失败,删除去重表中的数据
后续订单因为表中的唯一索引插入失败,返回操作失败,直到第一次请求完成(成功或者失败)
防重表的作用是实现加锁的功能
分布式锁
可以使用 Redis 分布式锁代替防重表的功能
示例:
订单发起支付请求
支付系统会去 Redis 缓存中查询是否存在该订单 Key
如果不存在,向 Redis 中增加 Key 为订单号
查询订单支付是否已经支付
如果没有则进行支付,支付完成后删除该订单的 Key
通过 Redis 实现分布式锁,只有这次订单请求完成,下次请求才会进来
对比去重表,Redis 分布式锁将放并发做在缓存中,效率更高
同一时间只能完成一次支付请求
token 令牌
token 令牌分为两个阶段:
申请 token 阶段:
在进入到提交订单页面之前,需要订单系统根据用户信息向支付系统发起一次申请 token 的请求
支付系统将 token 保存到 Redis 缓存中,给支付阶段使用
支付阶段:
订单系统获取到申请的 token, 发起支付请求,
支付系统检查 Redis 是否存在该 token
如果存在,表示第一次发起支付请求,删除缓存中的 token 开始支付逻辑处理
如果缓存中不存在,表示非法请求
支付缓冲区
支付缓冲区:
将订单的支付请求都快速地接收下来,是一个快速接收请求的缓冲管道
使用异步任务处理管道中的数据,过滤调掉重复的待支付的数据
优点: 同步转异步,高吞吐
缺点: 无法及时返回支付结果,需要后续监听支付结果的异步返回
版权声明: 本文为 InfoQ 作者【攻城狮Chova】的原创文章。
原文链接:【http://xie.infoq.cn/article/360dfee12367cc6eeae2102c0】。文章转载请联系作者。
评论