数据库新增幂等操作_接口调用幂等性问题及解决方案

什么是接口调用幂等性问题？

现如今我们的系统大多拆分为分布式架构、微服务架构，一套系统中包含了多个子系统服务，而一个子系统服务往往会去调用另一个服务，而服务调用服务无非就是使用RPC通信或者RESTFUL，既然是通信，那么就有可能在服务器处理完毕后返回结果的时候挂掉，这个时候用户端发现很久没有反应，那么就会多次点击按钮，这样请求有多次，那么处理数据的结果是否要统一呢？那是肯定的！

接口幂等性就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的， 不会因为多次点击而产生了副作用：比如说支付场景，用户购买了商品支付扣款成功，但是返回结果的时候网络异常，此时钱已经扣了，用户再次点击按钮，此时会进行第二次扣款，返回结果成功，用户查询余额返发现多扣钱了，流水记录也变成了两条，这就没有保证接口的幂等性。

哪些情况需要防止接口幂等性问题？

1、用户多次点击按钮

2、用户页面回退再次提交

3、微服务互相调用，由于网络问题，导致请求失败，feign触发重试机制

4、其他业务情况

常见的幂等性和非幂等性例子

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

SELECT * FROM table WHER id = ?，无论执行多少次都不会改变状态，是天然的幂等。

UPDATE tab1 SET col1=1 WHERE col2 = 2，无论执行成功多少次状态都是一致的， 也是幂等操作。

delete from user where userid = 1，多次操作，结果一样，具备幂等性。

insert into user(userid,name) values(1,'a')，如userid为唯一主键， 即重复操作上面的业务，只会插入一条用户数据，具备幂等性。

UPDATE tab1 SET col1 = col1 + 1 WHERE col2 = 2，每次执行的结果都会发生变化，不是幂等的。

insert into user(userid,name) values(1,'a')，如userid不是主键，可以重复，那上面业务多次操作，数据都会新增多条，不具备幂等性。

幂等性解决方案

一、Token机制(后文代码示例)

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

2、然后调用业务接口请求时，把token携带过去，一般放在请求头部。

3、服务器判断token是否存在redis中，存在表示第一次请求，然后删除token，继续执行业务。

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

危险性：

1、先删除token还是后删除token的问题

①先删除可能导致，业务确实没有执行，重试还带上之前token，由于防重设计导致，请求还是不能执行。

②后删除可能导致，业务处理成功，但是服务闪断，出现超时，没有删除token，别人继续重试，导致业务被执行两次。

③最好设计为先删除token，如果业务调用失败，就重新获取token再次请求。

2、Token 获取、比较和删除必须是原子性

①redis.get(token) 、token.equals 、redis.del(token)如果这几个操作不是原子，可能导致，高并发下，都get到同样的数据，判断都成功，继续业务并发执行。

②可以在 redis使用lua脚本完成这个操作。

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

二、各种锁机制

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， 再执行上面的sgl语句时，就不会执行; 因为version已经变为2了，where条件就不成立。这样就保证了不管调用几次，只会真正的处理一次。乐观锁主要使用于处理读多写少的问题

3、业务层分布式锁

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

三、各种唯一约束

1、数据库唯一约束

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

2、redis set 防重

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

四、防重表

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

五、全局请求唯一id

调用接口时，生成一个唯一id, redis 将数据保存到集合中(去重)，存在即处理过。可以使用nginx设置每一个请求的唯一id;

proxy_ser_header X-Request-Id $request_id;

使用Token机制示例

这里采用的是将Token存入Redis中，以电商的提交订单为例。

提交订单的时候需要验证Token，那么这个Token是怎么来的呢？以这里的业务为例，业务流程是这样的：

在购物车里选择要购买的商品，点击结算，就会发送一个请求，在Redis中创建一个Token并设置过期时间，并带着这个Token跳转到订单确认页进行保存。

// 创建一个防重令牌

String token = UUID.randomUUID().toString().replace("-","");

// Key为用户order:token:加上用户id，这个前缀是为了区分这是用于订单token的

redisTemplate.opsForValue().set("order:token:" + userId,token,30, TimeUnit.MINUTES);

// 返回结果，跳转页面...

当确认订单无误之后，就可以点击立即提交。一但点击立即提交，就会立刻进行一些业务操作(比如：创建订单、锁定库存、删除购物车里的商品等)。但是在这些业务之前，需要先去取出Redis中的Token来与页面保存的Token进行对比。如果一致，则表明是第一次调用，处理后续业务。如果Redis中不存在这个Token，则表示不是第一次，则不处理后续业务。这就要保证取Redis中的Token、做比较、删除的操作是原子操作，即取出之后对比Token是否相同和删除Token这两个操作要是原子的，如果不是原子的，则在并发情况下会出问题，get到同样的数据。

// 用户Id

String userId = xxxVo.getUserId();

// 页面保存的token

String token = xxxVo.getOrderToken();

// 从数据库中获取的Token并做比对 - 使用lua脚本完成一个原子操作

// 这个脚本的意思：将Key取出来的值与传进来的ARGV值进行比对，如果相同执行删除操作，返回1，否则返回0

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

// 调用RedisTemplate的execute方法执行lua脚本

Long result = redisTemplate.execute(new DefaultRedisScript(script, Long.class), Arrays.asList("order:token:" + userId), orderToken);

if(result == 0L){

// 验证失败

}else{

// 验证成功，执行业务

}