接口幂等性的常见解决方案

一、使用token机制

1、服务端提供了发送 token 的接口。我们在分析业务的时候，哪些业务是存在幂等问题的，
就必须在执行业务前，先去获取 token，服务器会把 token 保存到 redis 中。

2、然后调用业务接口请求时，把 token 携带过去，一般放在请求头部。
3、服务器判断 token 是否存在 redis 中，存在表示当前token已缓存，说明是第一次请求，然后删除 token,继续执行业务逻辑

4、如果判断 token 不存在 redis 中，就表示是重复操作，直接返回重复标记给 client，这样
就保证了业务代码，不被重复执行。

 二、各种锁机制

1、悲观锁机制

悲观锁使用时一般伴随事务一起使用，数据锁定时间可能会很长，需要根据实际情况选用。
另外要注意的是，id 字段一定是主键或者唯一索引，不然可能造成锁表的结果，处理起来会
非常麻烦。悲观锁它是一种悲观的心里状态，对应于生活中悲观的人总是想着事情往坏的方向发展。它像是一个彻底地 loser，它认为别人每次去拿数据都会修改这条数据，所以每次拿数据的时候，都会使数据处于锁定状态。执行下面 sql 语句锁住该条记录：

select * from mumu_test where userid = 123 and act_id = 'spring' for update;

2、乐观锁机制

这种机制适用于执行更新操作的接口。

乐观锁心态很乐观，只是在更新数据那一刻锁表，其他时间不锁表，所以相对于悲观锁，效率更高。 我们一般通过数据库来实现乐观锁，比较通用的做法是增加一个时间戳version字段。

1.获取抽奖券：update mumu_test set lottery = lottery + 5, version = version + 1 where id = 123 and version = 1;
2.消耗抽奖券update mumu_test set lottery = lottery - 1, version = version + 1 where id = 123 and version = 2;

 

3、分布式锁机制

如果多个机器可能在同一时间同时处理相同的数据，比如多台机器定时任务都拿到了相同数
据处理，我们就可以加分布式锁，锁定此数据，处理完成后释放锁。获取到锁的必须先判断
这个数据是否被处理过

三、生成全局唯一ID

全局唯一ID，根据业务操作和内容生成全局唯一的ID，然后在执行操作前先判断是否已经存在该ID，如果不存在则将该ID进行持久化(存在数据库或者redis中)，如果已经存在则证明该接口已经被调用过了。比如下单时可以生产一个流水号来作为该订单的唯一标识。