如何实现接口幂等性

helloworld6379

已于 2023-05-05 10:13:19 修改

阅读量857

点赞数

文章标签： java 接口接口幂等幂等

于 2023-03-07 15:43:50 首次发布

本文链接：https://blog.csdn.net/lx9876lx/article/details/129382766

版权

1 什么是幂等

幂等操作的特点是一次或者任意多次执行所产生的影响均与一次执行的影响相同，不会因为多次的请求而产生不一样的结果。换句话说，就是我使用相同的请求参数，去请求同一个接口，不管请求多少次获取到的响应数据应该是一样的（当然这里排查程序之外的其他如网络和设备等的异常所造成的不一样的结果）。

2 为什么需要实现幂等性

前端重复提交表单：在填写一些表格时候，用户填写完成提交，很多时候会因网络波动没有及时对用户做出提交成功响应，致使用户认为没有成功提交，然后一直点提交按钮，这时就会发生重复提交表单请求。
用户恶意进行刷单：例如在实现用户投票这种功能时，如果用户针对一个用户进行重复提交投票，这样会导致接口接收到用户重复提交的投票信息，这样会使投票结果与事实严重不符。
接口超时重复提交：很多时候 HTTP 客户端工具都默认开启超时重试的机制，尤其是第三方调用接口时候，为了防止网络波动超时等造成的请求失败，都会添加重试机制，导致一个请求提交多次。
消息进行重复消费：当使用 MQ 消息中间件时候，如果发生消息中间件出现错误未及时提交消费信息，导致发生重复消费。

使用幂等性最大的优势在于使接口保证任何幂等性操作，免去因重试等造成系统产生的未知的问题。

3 解决方案

实际业务中查询和删除本就是幂等。
所以只需考虑新增和修改操作的幂等性。

3.1 数据库唯一key

利用数据库中主键唯一约束的特性，避免插入重复数据。

3.2 分布式锁

将业务的key或code作为redis分布式锁的键进行加锁。
在这里插入图片描述

失效场景：
场景一：用户快速点击提交，连续发起两次请求。第一次请求先到达服务端，然后第二次请求由于某些原因过了一会儿才到达服务端。等第二次请求达到服务端的时候，第一次请求已经执行完毕并且释放了锁。此时第二次请求仍然能加锁成功，并且执行业务逻辑，这种情况下幂等性失效。

场景二：客户端发起第一次请求，服务端正常执行完毕并释放了分布式锁，但由于网络原因客户端没有正常收到服务端的响应，此时客户端再次发起请求。由于第一次请求所加的分布式锁已经过期所以第二次请求仍然能够加锁成功，然后执行业务逻辑，此时幂等性失效。

3.3 乐观锁

对需要操作的数据加上version字段，每次操作前获取version的值。操作时对version进行累加。

update tablename set count=count+1,version=version+1 where version=#{version}

这种适用于修改操作

3.4 token令牌

调用方在调用接口的时候先向后端请求一个全局 ID（Token），请求的时候携带这个全局 ID 一起请求（Token 最好将其放到 Headers 中），后端需要对这个 Token 作为 Key，用户信息作为 Value 到 Redis 中进行键值内容校验，如果 Key 存在且 Value 匹配就执行删除命令，然后正常执行后面的业务逻辑。如果不存在对应的 Key 或 Value 不匹配就返回重复执行的错误信息，以此来保证幂等操作。

在这里插入图片描述

3.5 加悲观锁

1）支付场景在加减库存场景中，用户A的账号余额有150元，想转出100元，正常情况下用户A
的余额只剩50元。一般情况下，sql是这样的：

update user amount = amount-100 where id=123;

如果出现多次相同的请求，可能会导致用户A的余额变成负数。这是很严重的系统bug。
为了解决这个问题，可以加悲观锁，将用户A的那行数据锁住，在同一时刻只允许一个请求获得
锁，更新数据，其他的请求则等待。通常情况下通过如下sql锁住单行数据。

select * from user id=123 for update;

具体流程如下：
在这里插入图片描述
具体步骤：

多个请求同时根据id查询用户信息。
判断余额是否不足100，如果余额不足，则直接返回余额不足。
如果余额充足，则通过for update再次查询用户信息，并且尝试获取锁。
只有第一个请求能获取到行锁，其余没有获取锁的请求，则等待下一次获取锁的机会。
第一个请求获取到锁之后，判断余额是否不足100，如果余额足够，则进行update操作。
如果余额不足，说明是重复请求，则直接返回成功。

2）操作库存场景

 select* from stock_info where goods_id=12312 and storage_id=1 for update;

具体流程：
a:单件货品操作流程
在这里插入图片描述
b:（同一个goodsId)多个单件货品，批量操作出库流程。

具体步骤：

多个请求同时根据goodsId和storageId操作货品的上下架，或者其他渠道订单批量下架操
作
判断当前货品是否有仓库货品
如果货品库存充足，则通过for update再次查询货品库存信息，并且尝试获取锁。
只有第一个请求能获取到行锁，其余没有获取锁的请求，则等待下一次获取锁的机会。
第一个请求获取到锁之后，进行货品单件明细状态变更，成功后操作，则进行update操作
加减库存。
如果库存不足或者单件不满足操作，则直接返回成功或者幂等状态。

需要特别注意的是：如果使用的是mysql数据库，存储引擎必须用innodb，因为它才支持事
务。此外，这里id字段一定要是主键或者唯一索引，不然会锁住整张表。

悲观锁需要在同一个事务操作过程中锁住一行数据，如果事务耗时比较长，会造成大量的请求等待，影响接口性能。此外，每次请求接口很难保证都有相同的返回值，所以不适合幂等性设计场景，但是在防重场景中是可以的使用的。防重设计和幂等设计其实是有区别的。防重设计主要为了避免产生重复数据，对接口返回没有太多要求。而幂等设计除了避免产生重复数据之外，还要求每次请求都返回一样的结果