接口调用幂等性问题及解决方案

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

现如今我们的系统大多拆分为分布式架构、微服务架构，一套系统中包含了多个子系统服务，而一个子系统服务往往会去调用另一个服务，而服务调用服务无非就是使用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 获取、比较和删除必须是原子性</