前任在代码里下毒，支付下单居然没加幂等?

首先蜗牛和大家从以下几个方面好好剖析一下接口幂等吧。

什么是接口幂等

比较专业的术语：其任意多次执行所产生的影响均与第一次执行的影响相同。

也就是多次调用的情况下，接口最终得到的结果是一致的。

那么为什么需要幂等呢？

那么哪些接口需要做幂等呢？

接口幂等的实现某种意义上是要消耗系统性能的，我们没有必要针对所有业务接口都加上幂等。

既然我们说幂等就是多次调用，接口最终得到结果一致，那么很显然，查询接口肯定是不要加幂等的，另外一些简单删除数据的接口，无论是逻辑删除还是物理删除，看场景的情况下其实也不用加幂等。

但是大部分涉及到多表更新行为的接口，咱们最好还是得加上幂等。

接口幂等实战方案

前端防抖处理

前端防抖主要可以有两种方案，一种是技术层面的，一种是产品层面的：

技术层面：例如提交控制在100ms内，同一个用户最多只能做一次订单提交的操作。
产品层面：当然用户点击提交之后，按钮直接置灰。

基于数据库唯一索引

利用数据库唯一索引。
我们具体来看一下流程，如下：

过程描述：

数据库乐观锁实现

什么是乐观锁，它总是假设最好的情况，每次去拿数据的时候都认为别人不会修改，所以不会上锁，只在更新的时候会判断一下在此期间别人有没有去更新这个数据。

例如提交订单的进行支付扣款的时候，本来可能更新账户金额扣款的动作是这样的：

update Account set balance = balance-#{payAmount} where accountCode = #{accountCode}

加上版本号之后，咱们的代码就是这样的。

update Account set balance = balance-#{payAmount},version=version +1 where accountCode = #{accountCode} and version = #{currVersion}

这种情况下其实就要求客户端每次在请求支付下单的时候都需要上层客户端指定好当前的版本信息。

数据库悲观锁实现

悲观锁的话具有强烈的独占和排他特性。

所以我们就用select ... for update这样的语法进行行锁，当然蜗牛觉得单纯的select ... for update只能解决同一时刻大并发的幂等，所以要保证单号重试这样非并发的幂等请求还是得去校验当前数据的状态才行。

悲观锁

begin;  # 1.开始事务
select * from order where order_code='666' for update # 查询订单，判断状态,锁住这条记录
if（status !=处理中）{//非处理中状态，直接返回；return ;
}
## 处理业务逻辑
update order set status='完成' where order_code='666' # 更新完成
update stock set num = num - 1 where spu='xxx' # 库存更新
commit; # 5.提交事务

这边想要强调的是在校验的时候还是得带上本身的业务状态去做校验，select ... for update并非万能幂等。