接口的幂等性，可以理解为无论这个接口调用多少次，最后只会执行一次。比如表单或者订单，如果多次提交肯定会影响我们正常的业务，因此做好接口幂等性非常重要。

首先聊一下Delete操作的幂等性：

首先，我们可以使用唯一业务号去删除。但是很可能我们在删除的过程中，遇到第一次删除时，已经将业务数据删除了，但是调用这个接口的过程中出错了，那么等第二次我们再去执行这个操作时，由于找不到数据，所以返回的数据是0，虽然对业务数据并没有其他影响，但是操作并不是很完美。所以最好的办法是在操作前先查询一下该业务数据是否存在来判断是否要执行删除操作。

其次，假如我们的删除操作并没有唯一业务号，则可以根据业务需求来判断。例如：需要删除审核未通过的商品。那么这个时候删除商品的标准可能是商品的当前状态了。假如第一次执行删除审核未通过的商品，在执行第二次删除之前恰好又有了新的审核未通过的商品，那么这个时候需不需要删除做幂等性处理就看具体的业务需求了。

其次聊一下Update操作的幂等性：

首先，我们可以使用唯一业务号去更新。用户查询出需要修改的数据，系统将数据返回到页面，将数据版本号放入隐藏域。在并发编程中，我们通常乐观锁机制也就是所谓的版本号进行控制。用户修改数据，点击提交，将版本号一同提交给后台。后台使用版本号作为更新条件，使用类似于下面的语句：

假如有个操作时用户修改自己的昵称，在第一次发送修改请求的时候，服务器还未给响应，就发起了第二次修改请求，就会导致两次修改，这个时候就需要做接口幂等性，使用乐观锁和update行锁来保证幂等性。

其次，假如我们的更新操作并没有唯一业务号，则可以使用token机制来保证幂等性。

最后聊一下Insert操作的幂等性：

首先，我们可以使用唯一业务号去新增。例如秒杀：商品id+用户id或者用户注册多次点击。

可以通过分布式锁，来保证接口的幂等性。业务执行结束后，不执行释放分布式锁，等锁时间自动过期自动释放。

假如没有唯一业务号，可以统一使用token机制来解决，来保证接口的幂等性。用户进入到注册页的时候，后台生成token，返回前台隐藏域中，用户在点击提交的时候，带上token一同传入后台。使用token获取分布式锁，完成insert操作。

混合操作：

意思是操作中可能包含多个Insert还有多个Update等，也可以用token的机制来做到接口的幂等性。分布式锁呢可以使用zookeeper或者redisson来实现。

附上一段redis的原子性操作脚本：（此方法可以作为解决幂等性操作的解决方案，保持原子性）

String script ="if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";

// 这里使用Long类型，查看源码可知脚本返回值类型只支持Long, Boolean, List, or deserialized value type.

DefaultRedisScript redisScript =new DefaultRedisScript<>();

redisScript.setScriptText(script);

redisScript.setResultType(Long.class);

// 设置key

List keyList =new ArrayList<>();

keyList.add("你之前设置的KEY");

//原子性验证令牌

Long result =redisTemplate.execute(redisScript, keyList,"你之前设置KEY对应的VALUE");

if(result ==1L){

//验证成功

    System.out.println("执行业务");

return "success";

}else {

//验证失败

    return "fail";

}