幂等的实现方案

在软件系统的开发过程中，我们可能有如下需求：

创建业务订单，一次业务请求只能创建一个；
单个订单请求调用支付接口，当遇到网络或系统故障请求重发，也应该只支付一次；
单个订单完成时，给用户发送消息应该只发一次；
等等很多情况下，都需要幂等的特性来支持。

幂等（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。