保证接口幂等性的解决方案（后台）

Posted 2021-03-24 yanggb

假如有个服务提供一个接口（服务部署在多个服务机器），接着有个接口是付款接口。用户在前端上操作的时候，一个订单不小心发起了两次支付请求，然后这两个请求分散在了这个服务部署的不同的机器上，结果一个订单扣款扣两次。这样的场景，就是接口没有保证幂等性的结果。

保证幂等性的核心

1.对于每个请求必须有一个唯一的标识。

2.每次处理完请求之后，必须有一个记录标识这个请求处理过了。

3.每次接收请求需要进行判断之前是否处理过的逻辑处理。

常见解决方案

1.业务表内唯一索引

如果要对创建销售出库单的接口保证幂等性，也就是说人家网络超时，重复调用的时候，保证一个订单只能有一个对应的销售出库单。针对销售出库单的表的订单id，创建一个唯一索引，你如果接口被重试，同一个订单创建一个销售出库单的话，一定会违反唯一索引，那么此时会报错。

2.业务表内状态机

修改订单状态，比如说将订单状态修改为【待发货】的时候，订单的状态其实就变为了【待发货】。

update order set status = ‘待发货‘ where status = ‘待付款‘ and id = 1;

这时候如果id为1的订单接口被重复调用了，即使再执行一次这个操作也不会有效果，因为这时候该订单记录的状态字段已经改变了，SQL并不会命中该记录。

在这种业务场景中也是通常都会有逻辑判断的，比如当前是否处于某个状态，然后才能流转到下一个状态（状态为待付款的才能流转到待发货）。

3.基于版本号的更新

id	name	age	version
1	yanggb	18	1

给业务表内添加一个版本号的字段，如果要调用一个接口去更新年龄之前，就需要先查一下他的版本号是多少，然后调用接口的时候带上版本号。

在接口里保证分布式接口的幂等性（在更新的SQL中添加version的条件判断）：

update user set age = 21, version = version + 1 where id = 1 and version = 1;

这样，多次提交的请求，因为版本号（version）都一样，因为第一次请求执行成功之后version已经+1了，则后面的请求因为version对应不上，都不会被执行。

4.基于mysql的去重表 / 基于Redis的去重

比如说接口方法为changeAge(1, 21, 1)，可以将所有的参数拼接成一个字符串，或者是从这些入参里选择一些参数（可以唯一标识这一次请求的一些参数），每次请求进来，在操作之前先校验这个字符串，如果校验通过则继续执行操作，校验失败则跳过。

如果基于MySQL，可以单独搞一个表出来（可以就一个字段），在这个表上的一个字段建一个唯一索引，插入的记录值就是前面拼接的字符串。因为第一次请求到达的时候，这个字符串在表中还不存在对应的记录，则会往表中插入该记录，并继续执行业务逻辑。后面的请求再到达的时候，因为这个字符串在表中已经存在了对应的记录了，唯一索引就会报一个冲突出来，这次插入就会失败，后续的业务逻辑也就会跳过执行了。

如果接口调用量很大，并发很高，还可以选择使用Redis。同样是拼接一个字符串串出来，直接set设置到Redis里去，如果下一次请求再过来，会发现这个key已经存在了，那么这个时候就不能执行了，因为已经可以知道出现了重复调用的情况了。

幂等的缺点

幂等是为了简化客户端逻辑处理，但是却增加了服务提供者的逻辑和成本，是否有必要在系统中引入幂等，需要根据具体场景具体分析，因此除了业务上的特殊要求外，一般建议是尽量不提供幂等的接口。

1.增加了额外控制幂等的业务逻辑，复杂化了业务功能。

2.把并行执行的功能改为串行执行，降低了执行效率。

 

"人不能太深情的活着，也不能总是追缅过去。"