1 什么是幂等
幂等操作的特点是一次或者任意多次执行所产生的影响均与一次执行的影响相同，不会因为多次的请求而产生不一样的结果。换句话说，就是我使用相同的请求参数，去请求同一个接口，不管请求多少次获取到的响应数据应该是一样的（当然这里排查程序之外的其他如网络和设备等的异常所造成的不一样的结果）。
2 为什么需要实现幂等性
前端重复提交表单： 在填写一些表格时候，用户填写完成提交，很多时候会因网络波动没有及时对用户做出提交成功响应，致使用户认为没有成功提交，然后一直点提交按钮，这时就会发生重复提交表单请求。
用户恶意进行刷单： 例如在实现用户投票这种功能时，如果用户针对一个用户进行重复提交投票，这样会导致接口接收到用户重复提交的投票信息，这样会使投票结果与事实严重不符。
接口超时重复提交： 很多时候 HTTP 客户端工具都默认开启超时重试的机制，尤其是第三方调用接口时候，为了防止网络波动超时等造成的请求失败，都会添加重试机制，导致一个请求提交多次。
消息进行重复消费： 当使用 MQ 消息中间件时候，如果发生消息中间件出现错误未及时提交消费信息，导致发生重复消费。
使用幂等性最大的优势在于使接口保证任何幂等性操作，免去因重试等造成系统产生的未知的问题。
3 解决方案
实际业务中查询和删除本就是幂等。
所以只需考虑新增和修改操作的幂等性。
3.1 数据库唯一key
利用数据库中主键唯一约束的特性，避免插入重复数据。
3.2 分布式锁
将业务的key或code作为redis分布式锁的键进行加锁。
失效场景：
场景一：用户快速点击提交，连续发起两次请求。第一次请求先到达服务端，然后第二次请求由于某些原因过了一会儿才到达服务端。等第二次请求达到服务端的时候，第一次请求已经执行完毕并且释放了锁。此时第二次请求仍然能加锁成功，并且执行业务逻辑，这种情况下幂等性失效。
场景二：客户端发起第一次请求，服务端正常执行完毕并释放了分布式锁，但由于网络原因客户端没有正常收到服务端的响应，此时客户端再次发起请求。由于第一次请求所加的分布式锁已经过期所以第二次请求仍然能够加锁成功，然后执行业务逻辑，此时幂等性失效。
3.3 乐观锁
对需要操作的数据加上version字段，每次操作前获取version的值。操作时对version进行累加。
update tablename set count=count+1,version=version+1 where version=#{version}
这种适用于修改操作
3.4 token令牌
调用方在调用接口的时候先向后端请求一个全局 ID（Token），请求的时候携带这个全局 ID 一起请求（Token 最好将其放到 Headers 中），后端需要对这个 Token 作为 Key，用户信息作为 Value 到 Redis 中进行键值内容校验，如果 Key 存在且 Value 匹配就执行删除命令，然后正常执行后面的业务逻辑。如果不存在对应的 Key 或 Value 不匹配就返回重复执行的错误信息，以此来保证幂等操作。
