✅如何解决接口幂等的问题？
典型回答
所谓幂等 ，一般分为两种，请求幂等和业务幂等，我们在软件开发领域，一般都是说的业务幂等。
请求幂等：每次请求，如果参数一样，结果也要一样。
业务幂等：同一次业务请求，在拿到最终状态之后的每次请求，结果要保证一样。在没拿到最终状态之前，每一次请求需要正常执行业务逻辑，直到推进到最终状态。
比如我们通常是这么做业务幂等的：一次支付请求，如果支付返回处理中，或者系统异常等，我们需要重试，继续调用，直到他明确的返回支付成功，或者明确的无法成功的支付失败结果。
一般来说，在幂等请求中，应该如下返回：
success = true
responseCode = DUPLICATED这样既能让别人知道是成功了，也能知道是因为幂等而导致的成功。
想要实现幂等，最简单的办法就是先查询一把本次操作是否处理过，如果已经处理成功，则直接返回查询到的结果，否则就去处理业务操作。
但是这个方案存在一个关键的问题，那就是如果出现了并发，就会出现多个接口查询的时候发现都没处理过，然后就都去执行业务操作，这时候就出现了并发问题。
根据并发出现的概率大小，我们分为不同的方案介绍。如果想要完整方案，直接跳过低并发，去看"一锁、二判、三更新“这个高并发方案就好了。
低并发场景下的方案
如果业务是低并发的话，有一种方案，那就是基于数据库的唯一性约束做幂等处理，简单点的伪代码如下：
public OrderResponse apply(OrderRequest request) {
OrderResponse response = new OrderResponse();
try {
OrderDTO orderDTO = orderService.create(request);
response.setSuccess(true);
response.setData(orderDTO);
return response;
} catch (DuplicateKeyException e) {
// 捕获唯一约束冲突，说明该请求已经处理过
OrderDTO orderDTO = orderService.queryOrder(request.getProduct(), request.getIdentifier());
response.setSuccess(true);
response.setResponseCode("DUPLICATED");
response.setData(orderDTO);
}
}但是这个方案他有几个缺点，比如他依赖你的操作中需要有insert，这样才能触发唯一性约束的冲突。他需要依靠异常来控制业务流程等等。
但是好处就是简单，并且在并发不高的情况下，用这种很简单，和下面要讲的方案相比，还能减少一次加锁，和查询的操作。
其实除了高并发情况，对于那种机制的性能要求的场景，这个方案也比下面的方案要好一些，因为他的操作流程更少，更加简单。
高并发场景下的方案
高并发场景下，想要解决这个问题，只需要记住一句口令”一锁、二判、三更新"，只要严格遵守这个过程，那么就可以解决高并发问题。
一锁：第一步，先加锁。可以加分布式锁、或者悲观锁都可以。但是一定要是一个互斥锁！
二判：第二步，进行幂等性判断。可以基于状态机、流水表、唯一性索引等等进行重复操作的判断。
三更新：第三步，进行数据的更新，将数据进行持久化。
以下是个简单的示例：
//一锁：先加一个分布式锁
@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实现分布式锁，因为他是非阻塞（tryLock）的高效率的互斥锁。非常适合在幂等控制场景中。
二判这个过程，如果有操作流水，建议基于操作流水做幂等，并将幂等号作为唯一性约束，确保唯一性。如果没有流水，那么基于状态机也是可以的。
但是不管怎么样，数据库的唯一性约束都要加好，这是系统的最后一道防线。万一前面的锁失效了，这里也能控制得住不会产生脏数据。