接口幂等性

目录

什么是幂等性

哪些情况需要防止 

什么情况下需要幂等 

幂等解决方案 

token机制  

各种锁机制

数据库悲观锁 

数据库乐观锁 

业务层分布式锁 

各种唯一约束 

数据库唯一约束

redis set 防重 

防重表

全局请求唯一id 

---

什么是幂等性

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

哪些情况需要防止 

• 用户多次点击按钮
• 用户页面回退再次提交
• 微服务互相调用，由于网络问题，导致请求失败（feign触发重试机制） 

什么情况下需要幂等 

• 以SQL为例，有些操作是天然幂等的

1. SELECT * FROM TABLE WHERE ID = ？，无论执行多少次都不会改变状态，是天然幂等。
2. UPDATE TABLE SET COL1 = 1 WHERE COL2 = 2，多次操作状态都是一致的，也是幂等操作。
3. DELETE FROM TABLE WHERE USER_ID = 1，多次操作，具备幂都等性。
4. INSERT INTO TABLE（USER_ID， NAME）  VALUES（1，‘a’），如USER_ID为唯一主键，即使重复执行，数据库也只会插入一条数据，具备幂等性。
5. UPDATE TABLE SET COL1 = COL1 + 1 WHERE COL2 = 2，每次执行的结果都会发生变化，不是幂等。 
6. INSERT INTO TABLE（USER_ID， NAME）  VALUES（1，‘a’），如USER_ID不是主键，可以重复，每执行一次，都会插入一条数据，不具备幂等性。 

幂等解决方案 

token机制  

• 服务端提供发送token的接口。我们在分析业务的时候，哪些业务是存在幂等问题，就必须在执行业务前，先去获取token，服务器会把token保存到redis中。然后调用业务接口请求时，把token携带过去，一般放在请求头。服务器判断token是否存在redis中，存在标识第一次请求，然后删除token，继续执行业务。

       危险性：先删token还是后删token 

1. 先删token可能导致，业务确实没有执行，重试带上之前的token，由于防重设计导致，请求还是不能执行。
2. 后删token可能导致，业务处理成功，但是服务闪断，出现超时，没有删除token，别的请求继续重试，导致业务被执行两遍。
3. 我们最好设计为先删token，如果业务调用失败，就重新获取token再次请求。

        token获取、对比、删除必须是原子性

1. redis.get（token）、token.equals、redis.del（token）如果这三个操作不是原子，可能导致高并发下，都get到同样的数据，判断都成功，业务并发执行。
2. 可以在redis使用lua脚本完成这个操作：

if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end

各种锁机制

数据库悲观锁 

• select * from table where id = 1 for update；
• 悲观锁使用时一般随着事务一起使用，数据锁定时间可能会很长，需要根据实际情况选用。另外需要注意的是，id字段一定是主键或者唯一索引，不然可能造成锁表的结果。

数据库乐观锁 

• update table set col1 = col1 - 1， version = version + 1 where col2 = 1 and version = 1;
• 此方法适合更新的场景，根据version版本，也就是在操作数据库前获取当前version版本号，然后操作的时候带上此 version 号。

       乐观锁主要使用于处理读多写少的问题。

业务层分布式锁 

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

各种唯一约束 

数据库唯一约束

• 插入数据，应该按照唯一索引进行插入，比如订单号，相同的订单号就不可能有两条记录插入，我们在数据库层面防止重复。
• 这个机制是利用数据库的主键唯一约束的特性，解决在insert场景幂等问题。但主键的要求不是自增主键，这样就需要业务生成全局唯一的主键。
• 如果是分库分表的场景下，路由规则要保证相同请求下，落地在同一数据库和同一表中，要不然数据库主键约束就不起作用，因为不同数据库和表主键不相关。

redis set 防重 

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

       百度秒传功能

防重表

• 使用订单号作为去重表的唯一索引，把唯一索引插入去重表，在进行业务操作，且他们在同一个事物中，这个保证了重复请求时，因为去重表有唯一约束，导致请求失败，避免了幂等问题。这里需要注意的是，去重表和业务表应该在同一库中，这样就保证了在同一事物，即使业务失败，也会回滚去重表数据。 

全局请求唯一id 

• 调用接口时，生成一个唯一id，redis将数据保存到集合中（去重），存在即处理过，可以使 用 ngnix 设置每一个请求的唯一id：proxy_set_header  X-Request-id $request_id。