背景
在软件系统的开发过程中,我们可能有如下需求:
- 创建业务订单,一次业务请求只能创建一个;
- 单个订单请求调用支付接口,当遇到网络或系统故障请求重发,也应该只支付一次;
- 单个订单完成时,给用户发送消息应该只发一次;
等等很多情况下,都需要幂等的特性来支持。
幂等的概念
幂等(idempotence)一词原为数学上的概念,用一个最直观的数学式子表达为:
f(f(x)) = f(x)
对应到软件开发领域,即为同样的请求被执行一次与连续执行多次的效果是一样的,服务器的状态也是一样的,实际上就是接口的可重复调用
(包括时间和空间上两个维度)。
不是要求返回值完全相同,而且是指后续多余的调用对系统的数据一致性不造成破坏。对于写入类操作,如果第一次写入是成功的,后续的写入应该抛出异常或者空操作,或者执行了写入但是未对数据造成变化。对于读取类操作,需要保证其实现上是真正的读取,不能在读操作中夹带写操作。
幂等实现方案
幂等性不能脱离业务来讨论。
在不同的需求场景下,实现幂等的思路和方案也会不同,一般有如下通用方案:
1. MVCC(多版本并发控制)
这是乐观锁的一种实现,用于在数据库并发访问时的情况。当数据更新时需要去判断版本号是否一致,如果不一致,则无法对数据进行更新。例如请求支付接口进行扣款时:
update table_name set deposit = deposit-#{payment}, version = version + 1 where orderId = #{orderId} and version = #{version}
这里orderId可进一步设为主键或唯一索引,因为这样是行锁,否则更新操作时会锁表。乐观锁在对已有数据进行更新时既能保证效率,又能保证幂等。
2. 去重表
这是利用数据库表单的特性来实现幂等。以订单请求支付场景为例:
将订单号orderId设为去重表的唯一索引,每次请求支付都根据订单号向去重表中插入一条数据,只有插入成功才继续执行支付操作,相当于在事务的开始阶段加锁。
考虑两种失败的情况:
- Insert去重表失败,事务回滚,无任何影响;
- Insert去重表成功,支付业务操作失败,事务回滚,删除之前插入去重表的记录,无任何影响;
以上两种失败的情况下,事务的幂等性是可以保持的,避免了单个订单同时多次进行支付的情况。
下图为该支付场景下的时序图:
3. 分布式锁
与去重表思路相同,只是将对数据库的的访问转移到了对缓存(如redis)的访问,提高了效率。具体操作如下:
订单发起支付请求,支付系统会去redis缓存中查询是否存在该订单号orderId的key,如果不存在,则向redis增加key为订单号,然后开始实际支付操作;如果查询到存在该订单号的key,则不进行实际支付操作。无论支付操作成功或失败,在支付操作结果返回后,在缓存中删除该订单号key。