幂等解决方案

0. 幂等性介绍

接口幂等性就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的， 不会因
为多次点击而产生了副作用。

1.  token 机制

1、 服务端提供了发送 token 的接口。 我们在分析业务的时候， 哪些业务是存在幂等问题的，
就必须在执行业务前， 先去获取 token， 服务器会把 token 保存到 redis 中。
2、 然后调用业务接口请求时， 把 token 携带过去， 一般放在请求头部。
3、 服务器判断 token 是否存在 redis 中， 存在表示第一次请求， 然后删除 token,继续执行业
务。
4、 如果判断 token 不存在 redis 中， 就表示是重复操作， 直接返回重复标记给 client， 这样
就保证了业务代码， 不被重复执行。
 

注意：保证获取token，对比token，删除token为原子操作。

2.  各种锁机制

2.1 数据库悲观锁

数据锁定时间可能会很长。

2.2 数据库乐观锁

带上版本号更新。处理读多写少的问题。

2.3 业务层分布式锁

多个机器可能在同一时间同时处理相同的数据，加分布式锁， 锁定此数据， 处理完成后释放锁。

3. 各种唯一约束

3.1 数据库唯一约束

利用了数据库的主键唯一约束的特性。需要业务生成全局唯一的主键，分库分表场景下失效，因为不同的数据库和表主键不相关。

3.2 redis set 防重

很多数据需要处理， 只能被处理一次， 比如我们可以计算数据的 MD5 将其放入 redis 的 set，
每次处理数据， 先看这个 MD5 是否已经存在， 存在就不处理。
 

4. 防重表

例如使用订单号 orderNo 做为去重表的唯一索引， 把唯一索引插入去重表， 再进行业务操作， 且
他们在同一个事务中。

5. 全局请求唯一 id

生成一个唯一 id， redis 将数据保存到集合中（去重） ， 存在即处理过。
可以使用 nginx 设置每一个请求的唯一 id；
proxy_set_header X-Request-Id $request_id;