参考: https://mp.weixin.qq.com/s/8kM73SaR9DHQDr0baMrRdQ
# 什么是幂等性
幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数或幂等方法是指可以使用相同参数重复执行，并能获得相同结果的函数。这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。
# 为什么需要实现幂等性
主要是防止表单重复提交，等其他重复操作情况。如：
- 前端重复提交表单： 在填写一些表格时候，用户填写完成提交，很多时候会因网络波动没有及时对用户做出提交成功响应，致使用户认为没有成功提交，然后一直点提交按钮，这时就会发生重复提交表单请求。
- 用户恶意进行刷单： 例如在实现用户投票这种功能时，如果用户针对一个用户进行重复提交投票，这样会导致接口接收到用户重复提交的投票信息，这样会使投票结果与事实严重不符。
- 接口超时重复提交： 很多时候 HTTP 客户端工具都默认开启超时重试的机制，尤其是第三方调用接口时候，为了防止网络波动超时等造成的请求失败，都会添加重试机制，导致一个请求提交多次。
- 消息进行重复消费： 当使用 MQ 消息中间件时候，如果发生消息中间件出现错误未及时提交消费信息，导致发生重复消费。
# 实现幂等性的方法
- 唯一索引 – 防止新增脏数据
- token机制 – 防止页面重复提交
- 悲观锁 – 获取数据的时候加锁(锁表或锁行)
- 乐观锁 – 基于版本号version实现, 在更新数据那一刻校验数据
- 分布式锁 – redis(jedis、redisson)或zookeeper实现状态机 – 状态变更, 更新数据时判断状态
# 这里采用Token令牌
方案描述:
在调用接口的时候先向后端请求一个全局 ID（Token），请求的时候携带这个全局 ID 一起请求（Token 最好将其放到 Headers 中），后端需要对这个 Token 作为 Key，用户信息作为 Value 到 Redis 中进行键值内容校验，如果 Key 存在且 Value 匹配就执行删除命令，然后正常执行后面的业务逻辑。如果不存在对应的 Key 或 Value 不匹配就返回重复执行的错误信息，这样来保证幂等操作。
适用操作：
- 插入操作
- 更新操作
- 删除操作
使用限制：
- 需要生成全局唯一 Token 串；
- 需要使用第三方组件 Redis 进行数据效验；
主要流程：
- 服务端提供获取 Token 的接口，该 Token 可以是一个序列号，也可以是一个分布式 ID 或者 UUID 串。
- 客户端调用接口获取 Token，这时候服务端会生成一个 Token 串。
- 然后将该串存入 Redis 数据库中，以该 Token 作为 Redis 的键（注意设置过期时间）。
- 将 Token 返回到客户端，客户端拿到后应存到表单隐藏域中。
- 客户端在执行提交表单时，把 Token 存入到 Headers 中，执行业务请求带上该 Headers。
- 服务端接收到请求后从 Headers 中拿到 Token，然后根据 Token 到 Redis 中查找该 key 是否存在。
- 服务端根据 Redis 中是否存该 key 进行判断，如果存在就将该 key 删除，然后正常执行业务逻辑。如果不存在就抛异常，返回重复提交的错误信息。
注意，在并发情况下，执行 Redis 查找数据与删除
需要保证原子性，否则很可能在并发下无法保证幂等性。其实现方法可以使用分布式锁或者使用 Lua 表达式来注销查询与删除操作。
# 总结
需要针对不同的业务场景我们需要灵活的选择幂等性的实现方式：
- 对于下单等存在唯一主键的，可以使用“唯一主键方案”的方式实现。
- 对于更新订单状态等相关的更新场景操作，使用“乐观锁方案”实现更为简单。
- 对于上下游这种，下游请求上游，上游服务可以使用“下游传递唯一序列号方案”更为合理。
- 类似于前端重复提交、重复下单、没有唯一ID号的场景，可以通过 Token 与 Redis 配合的“防重 Token 方案”实现更为快捷。
| 方案名称 | 适用方法 | 复杂度 | 缺点 |
|---|---|---|---|
| 数据库唯一主键 | 插入操作 删除操作 | 简单 | - 只能用于插入操作； - 只能用于存在唯一主键场景； |
| 数据库乐观锁 | 更新操作 | 简单 | - 只能用于更新操作；- 表中需要额外添加字段； |
| 请求序列号 | 插入操作 更新操作 删除操作 | 简单 | - 需要保证下游生成唯一序列号；- 需要 Redis 第三方存储已经请求的序列号； |
| 防重 Token 令牌 | 插入操作 更新操作 删除操作 | 适中 | - 需要 Redis 第三方存储生成的 Token 串； |