【微服务】--接口幂等性

什么是接口幂等性

接口幂等性是指：某些接口在被调用任意次数后，此接口对数据的操作每次结果都是相同的，即第一次操作和第N次操作接口的结果都是相同的，就像数学中某些数字的任意次幂其结果也都是数字本身。

不会产生接口幂等性的操作

在Java中有些操作其本身就是天然幂等性的，例如查询操作、删除操作、以下两条语句无论执行任意次，其结果都是相同的。

select * from user where id= 1，

delete from user where id=1，

部分更新操作，部分插入操作。

update user set age = 44 where id = 2

假设name字段或age字段有唯一性约束，此类的插入将是幂等性的操作

insert into user (name,age) values ('张三',33)

一个接口至少进行两次参数相同的操作，如果其结果都是相同的，那么则此接口就具有幂等性，否则反之。

那些情况下会发生接口幂等的问题

用户快速多次点击付款按钮 ，
用户页面回退再次提交，
由于网络问题，导致请求失败。 触发重试机制
自动提交的操作
…

解决接口幂等的方案

Token 机制
利用Token 令牌防止重复操作。在用户操作前向服务器获取一个具有唯一性的Token ，在操作时携带此Token ，由服务端验证此Token 是否存在，不存在则抛弃本次请求，如果存在则在验证token之后操作接口之前删除Token 。Token 可以存储在 Reids 数据库提高性能。

Token 获取、比较和删除必须是原子性。 redis.get(token) 、token.equals、redis.del(token)，如果操作不具有原子性，可能导致，高并发下，都 get 到同样的数据，判断都成功，继续业务并发执行。

使用锁机制

1. 数据库悲观锁
   select * from xxxx where id = 1 for update; 悲观锁使用时一般伴随事务一起使用，数据锁定时间可能会很长，需要根据实际情况选用。 另外要注意的是，id 字段一定是主键或者唯一索引，不然可能造成锁表的结果，处理起来会 非常麻烦。

2. 数据库乐观锁
   这种方法适合在更新的场景中， update t_goods set count = count -1 , version = version + 1 where good_id=2 and version = 1 根据 version 版本，也就是在操作库存前先获取当前商品的 version 版本号，然后操作的时候 带上此 version 号。我们梳理下，我们第一次操作库存时，得到 version 为 1，调用库存服务 version 变成了 2；但返回给订单服务出现了问题，订单服务又一次发起调用库存服务，当订 单服务传如的 version 还是 1，再执行上面的 SQL 语句时，就不会执行；因为 version 已经变 为 2 了，where 条件就不成立。这样就保证了不管调用几次，只会真正的处理一次。 乐观锁主要使用于处理读多写少的问题。

业务层分布式锁

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

各种唯一约束

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

Redis set 防重

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

全局请求唯一 id

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