✅如何解决接口幂等的问题？

典型回答

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

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

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

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

以下是个简单的示例：

//一锁：先加一个分布式锁
@DistributeLock(scene = "OEDER", keyExpression = "#request.identifier", expire = 3000)
public OrderResponse apply(OrderRequest request) {
    OrderResponse response = new OrderResponse();
    //二判：判断请求是否执行成功过
    OrderDTO orderDTO = orderService.queryOrder(request.getProduct(), request.getIdentifier());
    if (orderDTO != null) {
        response.setSuccess(true);
        response.setResponseCode("DUPLICATED");
        return response;
    }

        //三更新：执行更新的业务逻辑
    return orderService.order(request);
}

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

以上操作需要有一个前提，那就是第一步加锁、和第二步判断的时候，需要有一个依据，这个就是幂等号了，通常需要和上游约定一个唯一ID作为幂等号。然后通过对幂等号加锁，再通过幂等号进行幂等判断即可。

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

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

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

扩展知识

为什么不用数据库唯一性约束控制幂等

✅为什么不建议用数据库唯一性约束做幂等控制？

一锁不是必须的

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

✅高并发场景中，乐观锁和悲观锁哪个更适合？

请求幂等与业务幂等

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

业务幂等：同一次业务请求，再拿到最终状态之后的每次请求，结果要保证一样。再没拿到最终状态之前，每一次请求需要正常执行业务逻辑，直到推进到最终状态。

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

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

success = true
responseCode = DUPLICATED

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

锁和事务粒度要掌握好

✅用了一锁二查三更新，为啥还出现了重复数据？

原文: https://www.yuque.com/hollis666/xkm7k3/gz2qwl