接口幂等性

一、概念

当微服务之间调用时服务A向服务B重复发送消息或者用户多次点击导致重复操作数据库。

例如支付订单接口，如果发生网络问题，导致客户端重复请求两次，就会导致扣款两次。
例如向数据库写入数据，重复请求会导致数据库中出现重复的脏数据。
幂等性就是说一个接口需要保证发生多次重复的请求，只有一次请求生效。
①对于每个请求需要有一个唯一的标识，如订单支付请求，需要包含订单的id，一个id最多支付一次
②处理完成后，需要有一个记录标识这个请求已经处理完成。

image.png

二、实现幂等性的思路

• 1.全局唯一id：需要根据实际业务生成,操作执行成功后生成这个id,每次执行操作前先判断这个id存不存在,存在就是已执行,不存在则添加这个id.
• 2.去重表：就是利用数据库的唯一约束.如果重复新增某个唯一标识,就会报唯一约束异常,再利用事务回滚.
• 3.利用版本号控制：多拥有更新操作.每次更新的时候需要在where条件中添加version判断,并更新version.如果版本已更新就无法再次根据原版本号更新了.
• 4.在并发不高的系统,可以在新增或更新操作执行前先对关键数据进行查询,并根据实际业务设置判断,通过后再执行操作

可以将以上操作编写为自定义注解，方便实现接口幂等性。

三、幂等解决方案

3.1 token机制（适用于下订单等操作）

流程

1. 在执行业务前，获取token，服务器会把token保存到redis中；
2. 然后调用业务接口请求时，把token携带过去，一般放在请求头；
3. 服务器判断token是否存在redis中，存在表示第一次请求，然后删除token，继续执行业务；
4. 如果判断token不存在redis中，就表示是重复操作，直接返回重复标记给client。保证了不会重复提交。

危险性
先删除token还是后删除token：先删除可能导致业务执行失败后无法再次提交成功需要再次提交表单，后删除可能导致业务处理成功但是没有删除token。采用先删除策略，但是需要保证redis操作的原子性。
解决措施：token获取、比较和删除必须是原子性的。可以使用分布式锁或在redis使用lua脚本完成。
if redis.call('get',KEYS[1]) == ARGV[1] then return redis.call('del',KEYS[1]) else return 0 end
将脚本提交到redis执行，保证原子性。

缺点
对代码的侵入性较强。

3.2 各种锁机制（适用于减库存等操作）

3.2.1 数据库悲观锁

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

3.2.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条件就不成立。保证了不会重复提交。
乐观锁主要使用于处理读多写少的问题。

3.2.3 分布式锁

多个节点同时处理相同的数据，可以使用分布式锁，锁定此数据，处理完成后释放锁。获取到锁的必须先判断这个数据是否被处理过。

3.3 各种唯一约束

3.3.1 数据库唯一约束

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

3.3.2 redis set 防重

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

3.4 防重表

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

上述使用的redis防重表同理。

3.5 全局请求唯一id（可以处理feign重复调用，不能处理客户端重复提交）

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