# 幂等机制
## 幂等场景
**场景一：前端重复提交**
用户注册，用户创建商品等操作，前端都会提交一些数据给后台服务，后台需要根据用户提交的数据在数据库中创建记录。如果用户不小心多点了几次，后端收到了好几次提交，这时就会在数据库中重复创建了多条记录。这就是接口没有幂等性带来的 bug。
**场景二：黑客拦截重放**
接口请求参数被黑客拦截，然后进行重放。
**场景三：接口超时重试**
对于给第三方调用的接口，有可能会因为网络原因而调用失败，这时，一般在设计的时候会对接口调用加上失败重试的机制。如果第一次调用已经执行了一半时，发生了网络异常。这时再次调用时就会因为脏数据的存在而出现调用异常。
**场景四：消息重复消费**
在使用消息中间件来处理消息队列，且手动 ack 确认消息被正常消费时。如果消费者突然断开连接，那么已经执行了一半的消息会重新放回队列。当消息被其他消费者重新消费时，如果没有幂等性，就会导致消息重复消费时结果异常，如数据库重复数据，数据库数据冲突，资源重复等。
## 解决方案
### Token机制实现
通过token机制实现接口的幂等性,这是一种比较通用性的实现方法。示意图如下：
具体流程步骤：
- 客户端会先发送一个请求去获取 token，服务端会生成一个全局唯一的 ID 作为 token 保存在 redis 中，同时把这个 ID 返回给客户端
- 客户端第二次调用业务请求的时候必须携带这个 token
- 服务端会校验这个 token，如果校验成功，则执行业务，并删除 redis 中的 token
- 如果校验失败，说明 redis 中已经没有对应的 token，则表示重复操作，直接返回指定的结果给客户端
注意：
- 对 redis 中是否存在 token 以及删除的代码逻辑建议用 Lua 脚本实现，保证原子性
- 全局唯一 ID 可以考虑用百度的 uid-generator、美团的 Leaf 去生成
**设计Token**
- 要申请，一次有效性，可以限流
- 使用删除操作来判断Token。删除成功代表校验通过
- 如果用 select+delete 来校验 Token，会存在并发问题，不建议使用，但可以用lua保证原子性
- 设置短期过期时间，如5分钟
