千家信息网

如何理解接口的幂等性的多重考虑

发表于:2024-11-25 作者:千家信息网编辑
千家信息网最后更新 2024年11月25日,本篇内容主要讲解"如何理解接口的幂等性的多重考虑",感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习"如何理解接口的幂等性的多重考虑"吧!正文1 接口幂等性就是说
千家信息网最后更新 2024年11月25日如何理解接口的幂等性的多重考虑

本篇内容主要讲解"如何理解接口的幂等性的多重考虑",感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷,实用性强。下面就让小编来带大家学习"如何理解接口的幂等性的多重考虑"吧!

正文

1 接口幂等性

就是说在多次相同的操作下保证最终的结果是一致的。

其实这个概念还是比较简单的,很容易理解,那我们思考一个问题,如果不保证接口幂等性会有什么问题

1.1 案例

我们简单的举个例子,现在有一个接口,提供了转账的功能,a要给b转账1000元,正常情况下我们接口一次性就调用成功了,但是却因为网络抖动等其它原因没有成功,于是就开始不停的重试,突然网络好了,但是这时却连续发出去了三个请求,但是这个接口没有保证幂等性,于是从结果上来看就是a给b转了3000元,这显然是程序业务逻辑上不能接受的(其实moon可以当b的)。

2 解决方案

2.1 token机制

token机制其实是比较简单的,我们先来简单的说一下流程。

  • 首先客户端先请求服务端,服务端生成token,每次请求生成的都是一个新的token(这个token一定要设置超时时间),将token存入redis当中,然后将token返回给客户端。

  • 客户端携带刚刚返回的token请求服务端做业务请求

  • 服务端收到请求,做判断。

    • 如果token在redis中,则直接删除该token,然后继续做业务请求。

    • 如果token不在redis中,代表已经执行过当前业务了,则不执行业务。

图示如下:

token机制实现方式还是比较简单的,但是其实对于我们某些响应速度要求很高的业务不太友好,缺点就是需要多一次请求获取token的过程

正常来说是每次请都会生成一个新的token,如果有极限情况下,有两个请求都带着相同的token进来,会存在都走入判断是否存在的过程,可能都会同时查到存在,这样也会有问题,针对这种情况,我们可以在删除前判断下是否存在,存在就删除,为了保证原子性,这部分逻辑建议使用lua脚本完成

2.2 去重表

去重表的机制是根据mysql唯一索引的特性来的,我们先来说下它的流程:

  • 首先客户端先请求服务端,服务端先将这次的请求信息存入一张mysql的去重表中,这张表要根据这次请求的其中某个特殊字段建立唯一索引,或者主键索引

  • 判断是否插入成功

    • 如果插入成功,则继续做后续业务请求。

    • 如果插入失败,则代表已经执行过当前请求。

图示如下:

去重表机制的问题有两点:

  • 1.mysql容错性,也就是mysql本身如果不是高可用的那么业务可能会受到影响:

  • 2.既然是唯一索引,自然在写表的时候就没有办法用到changbuffer,每次都要从磁盘查出来判断再写入,对于一个高并发的接口来说,这些都是需要考虑的因素。

2.3 redis 的 SETNX键值

过程如下:

  • 首先客户端先请求服务端,服务端将能代表这次请求业务的唯一字段以 SETNX 的方式存入redis,并设置超时时间,超时时间可以根据业务权衡。

  • 判断是否插入成功

    • 如果插入成功,则继续做后续业务请求。

    • 如果插入失败,则代表已经执行过当前请求。

这里我们是利用了redis setnx 的特性来完成的。

setnx:只在键key不存在的情况下,将键key的值设置为value。若键key已经存在,则SETNX命令不做任何动作。命令在设置成功时返回1,设置失败时返回0

图示如下:

这种方案可以说是针对上一个方案改进的,效率也会提高很多。

2.4 状态机幂

这种机制适用于有不同状态的业务,moon的上一家公司就是这样做的。

我们的订单系统,一条订单会有多个状态,如:待付款,锁定,已付款等状态,而这些状态都是有流程和逻辑的,我们可以根据这个状态判断是否执行后续业务操作。

2.5 乐观锁(更新操作)

就是数据库中增加版本号字段,每次更新根据版本号来判断

过程如下:

  • 首先客户端先请求服务端,先查询出当前的version版本。

    • select version from .. where ..

  • 根据version版本来做sql操作

    • UPDATE .. SET ... version=(version+1) WHERE .. AND version=version;

这个图示我就不再画了,还是比较简单的

2.6 悲观锁(更新操作)

假设每一次拿数据,都有认为会被修改,所以给数据库的行上锁,也是基于数据库特性来完成。

当数据库执行select for update时会获取被select中的数据行的行锁,因此其他并发执行的select for update如果试图选中同一行则会发生排斥(需要等待行锁被释放),因此达到锁的效果。

START TRANSACTION; # 开启事务SELETE * FROM TABLE WHERE .. FOR UPDATE;UPDATE TABLE SET ... WHERE ..;COMMIT; # 提交事务

到此,相信大家对"如何理解接口的幂等性的多重考虑"有了更深的了解,不妨来实际操作一番吧!这里是网站,更多相关内容可以进入相关频道进行查询,关注我们,继续学习!

0