前言：

接口幂等性是指一个接口在多次调用相同请求时，产生的结果与一次调用的结果相同。换句话说，无论请求被执行多少次，最终的效果都是一致的，不会因为多次调用而导致状态的变化。

为什么会产生接口幂等性问题？

• 网络波动, 可能会引起重复请求
• 用户重复操作,用户在操作时候可能会无意触发多次下单交易,甚至没有响应而有意触发多次交易应用
• 使用了失效或超时重试机制(Nginx重试、RPC重试或业务层重试等)
• 页面重复刷新
• 使用浏览器后退按钮重复之前的操作,导致重复提交表单
• 使用浏览器历史记录重复提交表单
• 浏览器重复的HTTP请求
• 定时任务重复执行
• 用户双击提交按钮

解决接口幂等性问题

解决接口幂等问题，，只需要记住一句口令"一锁、二判、三更新"，只要严格遵守这个过程，那么就可以解决并发问题。

一锁:第一步，先加锁。可以加分布式锁、或者悲观锁都可以。但是一定要是一个互斥锁!

二判:第二步，进行幂等性判断。可以基于状态机、流水表、唯一性索引等等进行重复操作的判断。

三更新:第三步，进行数据的更新，将数据进行持久化。

以下是个简单的示例：

//一锁:先加一个分布式锁
@DistributeLock(scene ="OEDER",keyExpression ="#request.identifier",expire = 3000)
 public orderResponse apply(orderRequest request){
OrderResponse response =new rderResponse);
OrderDTo orderDT0 =orderService.queryorder(request.getProduct),request.getIdentifier());
 //二判:判断请求是否执行成功过
if(orderDTo !=null){
    response.setsuccess(true);
    response.setResponseCode("DUPLICATED");
    return response;
}
   //三更新:执行更新的业务逻辑
   return orderservice.order(request);
  
}

三步需要严格控制顺序，确保加锁成功后进行数据查询和判断，幂等性判断通过后再更新，更新结束后释放锁。

一锁这个过程，建议使用Redis实现分布式锁，因为他是非阻塞的高效率的互斥锁。非常适合在幂等控制场景中。

二判这个过程，如果有操作流水，建议基于操作流水做幂等，并将幂等号作为唯一性约束，确保唯一性。如果没有流水，那么基于状态机也是可以的。

但是不管怎么样，数据库的唯一性约束都要加好，这是系统的最后一道防线。万一前面的锁失效了这里也能控制得住不会产生脏数据。

第一步加锁为了解决高并发场景下的幂等问题，如果没有高并发，不需要第一步了，就直接查询更新，再更新的时候做乐观锁控制就行了:

请求幂等与业务幂等

请求幂等:每次请求，如果参数一样，结果也要一样。

业务幂等:同一次业务请求，在拿到最终状态之后的每次请求，结果要保证一样。再没拿到最终状态。

比如，一次支付请求，如果支付返回处理中，或者系统异常等，我们需要重试，继续调用，直到他明确的返回支付成功，或者明确的无法成功的支付失败结果。

一般来说，在幂等请求中，应该如下返回:

success =true
responseCode = DUPLICATED

这样既能让别人知道是成功了，也能知道是因为幂等而导致的成功。

总结

接口幂等性问题也是在项目中经常考虑的点，做好接口幂等性对业务数据流控制至关重要的。在工作中大家可以参考上述方案进行接口幂等性控制。