如何保证接口的幂等性?常见的实现方案有哪些?
什么是幂等性
幂等用于表示任意多次请求均与一次请求执行的结果相同,也就是说对于一个接口而言,无论调用了多少次,最终得到的结果都是一样的。
如何保证接口的幂等性
1、前端拦截
2、使用数据库实现幂等性
3、使用 JVM 锁实现幂等性
4、使用分布式锁实现幂等性
保证接口的幂等性的实现过程
1、前端拦截
前端拦截是指通过 Web 站点的页面进行请求拦截,比如在用户点击完“提交”按钮后,我们可以把按钮设置为不可用或者隐藏状态,避免用户重复点击。
但前端拦截有一个致命的问题,如果是懂行的程序员或者黑客可以直接绕过页面的 JS 执行,直接模拟请求后端的接口,这样的话,我们前端的这些拦截就不能生效了。因此除了前端拦截一部分正常的误操作之外,后端的验证必不可少。
2、数据库实现
a、通过悲观锁来实现幂等性
b、通过唯一索引来实现幂等性
c、通过乐观锁来实现幂等性
3. JVM 锁实现
JVM 锁实现是指通过 JVM 提供的内置锁如 Lock 或者是 synchronized 来实现幂等性。使用 JVM 锁来实现幂等性的一般流程为:首先通过 Lock 对代码段进行加锁操作,然后再判断此订单是否已经被处理过,如果未处理则开启事务执行订单处理,处理完成之后提交事务并释放锁,如图所示
JVM 锁存在的最大问题在于,它只能应用于单机环境,因为 Lock 本身为单机锁,所以它就不适应于分布式多机环境。
4. 分布式锁实现
分布式锁实现幂等性的逻辑是,在每次执行方法之前先判断是否可以获取到分布式锁,如果可以,则表示为第一次执行方法,否则直接舍弃请求即可
幂等性需要注意什么问题
幂等性的实现与判断需要消耗一定的资源,因此不应该给每个接口都增加幂等性判断,要根据实际的业务情况和操作类型来进行区分。例如,我们在进行查询操作和删除操作时就无须进行幂等性判断。查询操作查一次和查多次的结果都是一致的,因此我们无须进行幂等性判断。删除操作也是一样,删除一次和删除多次都是把相关的数据进行删除(这里的删除指的是条件删除而不是删除所有数据),因此也无须进行幂等性判断。
实现幂等性的关键步骤有哪些
1、每个请求操作必须有唯一的 ID,而这个 ID 就是用来表示此业务是否被执行过的关键凭证,例如,订单支付业务的请求,就要使用订单的 ID 作为幂等性验证的 Key;
2、每次执行业务之前必须要先判断此业务是否已经被处理过;
3、第一次业务处理完成之后,要把此业务处理的状态进行保存,比如存储到 Redis 中或者是数据库中,这样才能防止业务被重复处理。
说一说数据库实现幂等性的执行细节
1、通过悲观锁来实现幂等性
2、通过唯一索引来实现幂等性
3、通过乐观锁来实现幂等性
① 悲观锁
使用悲观锁实现幂等性,一般是配合事务一起来实现。
在实现的过程中需要注意以下两个问题:
a、如果使用的是 MySQL 数据库,必须选用 innodb 存储引擎,因为 innodb 支持事务;
b、id 字段一定要是主键或者是唯一索引,不然会锁表,影响其他业务执行。
比如:
begin; # 1.开始事务
select * from table_name where id='xxx' for update; # 2.查询状态
insert into table_name (id) values ('xxx'); # 3.添加操作
update table_name set status='xxx'; # 4.更改操作
commit; # 5.提交事务
② 唯一索引
我们可以创建一个唯一索引的表来实现幂等性,在每次执行业务之前,先执行插入操作,因为唯一字段就是业务的 ID,因此如果重复插入的话会触发唯一约束而导致插入失败。在这种情况下(插入失败)我们就可以判定它为重复提交的请求。比如:
CREATE TABLE `table_name` (
`id` int NOT NULL AUTO_INCREMENT,
`orderid` varchar(32) NOT NULL DEFAULT '' COMMENT '唯一id',
PRIMARY KEY (`id`),
UNIQUE KEY `uq_orderid` (`orderid`) COMMENT '唯一约束'
) ENGINE=InnoDB;
③ 乐观锁
乐观锁是指在执行数据操作时(更改或添加)进行加锁操作,其他时间不加锁,因此相比于整个执行过程都加锁的悲观锁来说,它的执行效率要高很多。
乐观锁可以通过版本号来实现,例如以下 SQL:
update table_name set version=version+1 where version=0;