接口幂等性分析

什么是接口幂等性，在现在微服务、分布式越来越普遍的时代，接口幂等性也逐渐成为程序开发中必要考虑到的问题

什么是幂等

简单来说幂等就是操作多次与操作一次有着相同的结果，举个现实中的例子，比如你在双十一零点的时候买了一个商品，但是由于网络不好页面卡住了，而你又是一个暴脾气，对着支付按钮疯狂输出，结果导致你只买了一件商品，但是扣了n倍的钱，你说谁的锅？
而正确的情况应该是不论你点击几次，都只是一件商品下单一件商品付款，这就体现出接口幂等性的重要

常见的问题情况

就拿比较敏感的支付功能举例
1.多次点击支付按钮
2.接口之间调用的网络或其他问题导致的重试机制
…
上述的问题都会导致接口出现幂等问题，

幂等的区分

1.首先我们要针对具体情况做区分，例如对数据库的删除、查询操作是不会涉及到幂等问题的，这些操作天然幂等
2.而对于修改，和新增就要注意了，特别是修改，如果只是设置某个值为特定数值时
（update 表 字段=1 where 字段=2）类似于这样的操作也是属于天然幂等的，但是涉及到计算的
（update 表 字段=字段-1 where 字段=2）这样的那就要考虑幂等性问题了

解决幂等问题的方案

1 、token 机制

1、服务端提供了发送 token 的接口。我们在分析业务的时候，哪些业务是存在幂等问题的，
就必须在执行业务前，先去获取 token，服务器会把 token 保存到 redis 中。
2、然后调用业务接口请求时，把 token 携带过去，一般放在请求头部。
3、服务器判断 token 是否存在 redis 中，存在表示第一次请求，然后删除 token,继续执行业务。
4、如果判断 token 不存在 redis 中，就表示是重复操作，直接返回重复标记给 client，这样就保证了业务代码，不被重复执行。

危险性：

1、先删除 token 还是后删除 token；
(1) 先删除可能导致，业务确实没有执行，重试还带上之前 token，由于防重设计导致，请求还是不能执行。
(2) 后删除可能导致，业务处理成功，但是服务闪断，出现超时，没有删除 token，别人继续重试，导致业务被执行两遍
(3) 我们最好设计为先删除 token，如果业务调用失败，就重新获取 token 再次请求。
2、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
这里面的KEYS[1]指的是redis中的key ARGV[1]指的是传过来的token

2 、各种锁机制

1 、数据库悲观锁
悲观锁使用时一般伴随事务一起使用，数据锁定时间可能会很长，需要根据实际情况选用。
悲观锁实现方式
悲观锁的实现，往往依靠数据库提供的锁机制。在数据库中，悲观锁的流程如下：
在对记录进行修改前，先尝试为该记录加上排他锁（exclusive locking）。
如果加锁失败，说明该记录正在被修改，那么当前查询可能要等待或者抛出异常。具体响应方式由开发者根据实际需要决定。
如果成功加锁，那么就可以对记录做修改，事务完成后就会解锁了。
其间如果有其他事务对该记录做加锁的操作，都要等待当前事务解锁或直接抛出异常。
我们拿比较常用的MySql Innodb引擎举例，来说明一下在SQL中如何使用悲观锁。
注意：要使用悲观锁，我们必须关闭mysql数据库中自动提交的属性，命令set autocommit=0;即可关闭，因为MySQL默认使用autocommit模式，也就是说，当你执行一个更新操作后，MySQL会立刻将结果进行提交。
我们举一个简单的例子，如淘宝下单过程中扣减库存的需求说明一下如何使用悲观锁：

//0.开始事务
begin; 
//1.查询出商品库存信息
select quantity from items where id=1 for update;
//2.修改商品库存为2
update items set quantity=2 where id = 1;
//3.提交事务
commit;

以上，在对id = 1的记录修改前，先通过for update的方式进行加锁，然后再进行修改。这就是比较典型的悲观锁策略。

如果以上修改库存的代码发生并发，同一时间只有一个线程可以开启事务并获得id=1的锁，其它的事务必须等本次事务提交之后才能执行。这样我们可以保证当前的数据不会被其它事务修改。

上面我们提到，使用select…for update会把数据给锁住，不过我们需要注意一些锁的级别，MySQL InnoDB默认行级锁。行级锁都是基于索引的，如果一条SQL语句用不到索引是不会使用行级锁的，会使用表级锁把整张表锁住，所以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 条件就不成立。这样就保证了不管调用几次，只会真正的处理一次。
乐观锁主要使用于处理读多写少的问题
3、业务分布式锁
如果多个机器可能在同一时间同时处理相同的数据，比如多台机器定时任务都拿到了相同数据处理，我们就可以加分布式锁，锁定此数据，处理完成后释放锁。获取到锁的必须先判断这个数据是否被处理过。

3 、各种唯一约束

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

4 、防重表

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

5 、全局请求唯一 id

调用接口时，生成一个唯一 id，redis 将数据保存到集合中（去重），存在即处理过。该方法针对的时由于网络波动或调用超时导致远程调用接口重试机制多次发送相同的请求，而对调用接口的唯一id可以防止这现象