一. 幂等的概念
用在编程领域里, 则意为: 对同一个系统，使用同样的条件,一次请求和重复的多次请求对系统资源的影响是一致的。
在数学的定义里可以简单理解为: 在某运算下,幂等元素是指被自己重复运算的结果等于它自己的元素。 f(x) = f(f(x))
二. 幂等的场景
在我们实际的开发过程中, 例如: 支付接口调用, 交易下单等.
有以下场景:
系统B接口不支持幂等, A系统请求B系统支付接口进行支付. 因网络超时导致接口请求失败.
三. 关于接口的幂等设计
关于以上场景, A系统进行后续处理.
如果将接口请求判为失败, 显然是不合理的. 因为,可能是在B系统接收到支付请求之后,进行了扣款操作且扣款成功, 但是在接口返回时超时.
此时如果A系统再向B系统发起支付申请重试, 对于客户来说同一笔交易发生多次扣款, 造成客户损失.如果将接口请求判为成功, 也不合理. 因为,可能B系统根本就没有接收到支付请求, 客户也没法发生扣款操作, 而客户的订单状态却成功了. 对于商户来说会造成损失.
-
所以, 对与以上情况,都是不可取的. 正确的方式是:
- B系统在接口设计时, 定义一个对于每笔订单都是唯一的流水号编号字段, 同时在DB中对该字段维护唯一约束.
- 若A请求B网络超时, 那么A可以不更换交易流水号, 继续请求B系统对超时的交易进行重试. B系统在插入支付订单前, 先检查一下是否之前已经处理该笔交易.
如果未处理, 则直接交易落地, 并进行后续处理.
如果交易已处理,则返回给A系统此时的交易状态和结果.
假设在接口请求时发生并发, B系统也可以通过DB的唯一约束挡住另一笔并发的交易.
四. 关于接口防并发的处理方式
1.在接口方法上使用同步锁
- 优缺点: 实现简单. 但是只适用于非集群环境
2.分布式锁如redis
- 优缺点: 能挡住分布式系统的并发, 但是设计相对复杂(具体实现可以参考:分布式锁的实现).而且控制并发的代价是让接口在集群中都是单线程形式处理业务请求, 大大牺牲的接口性能. 并不可取
2.业务字段加唯一约束
- 优缺点: 简单实用, 但是需要另外维护该业务字段的生成规则(具体实现可以参考:分布式系统下如何生成唯一有序编号).
- 前端系统生成唯一性token+后端token字段落地并加唯一约束
- 优缺点: 方便实用
对客户端请求排队或者单线程都可以处理并发幂等问题，需要根据具体业务选择合适的方案但必须前后端一起做，前端做了可以提升用户体验，后端则可以保证数据安全。
五. 总结
//TODO
参考文章
如有问题,还请各位老师批评指正,谢谢~
