接口幂等性设计(5 大方案罗列)

结合案例、列举场景的接口幂等性设计方案。

方案 1. 状态机

业务场景,数据审核成功后进行短信通知,或者是订单状态变成已支付后,短信通知用户订单生成的详细信息,等等和状态有关的操作。

假设 status:0(待审核)、1(已审核)、2(已退回)。

批量审核场景幂等性代码设计

shtz 方法 中的 sql 语句如下:update tab_dzzzhz set status = 1 where (status = 0 or status = 2) and id = #{id}

生效原理:用的是Mysql,Mysql 中的 update 原理,先是对查询条件中命中的数据进行上锁,然后接着修改这条数据。因此当有多个请求打过来,对指定 id、status 的这条数据的更新时,其实是一个串行化操作。第一个请求更新好数据后,数据的 status 变为了 1,第二个请求过来,发现没有符合条件的数据要更新了,直接 return 0(影响的行数为 0)。此时代码中就可以认为此次更新操作是多余的。就避免了重复短信通知的问题

方案 2. redis 分布式锁

这个没啥好说的,就是利用 lua 脚本,保证对应 查询、更新操作 的业务逻辑是原子性的。至于 lua 脚本锁的 key 根据各位的业务逻辑来。
分布式会议室(幂等性校验、同一用户只能报名一次)

方案2与 方案 1 的区别在于,其实就是一个利用 mysql 的行锁、表锁机制实现的,一个是利用 redis 的 lua 脚本实现的。

方案 3.加唯一索引

之前有个业务场景就是必须保证生成,同一个证照编号的数据只能存在一条,而这个数据是掉第三方系统生成的,第三方系统可能存在 bug,同时发俩条一样证照编号的数据过来。此时我们的Mysql 表中由于,对证照编号加了唯一索引,因此在入库的时候,就能进行异常检测了。避免出现重复数据的问题。唯一索引可以是一个字段唯一、也可以是多个字段组合唯一

方案 4.利用Mysql 乐观锁、悲观锁

请挪步:一个小小的乐观锁、悲观锁也能扯这么多

方案 5.建立防重表

进行查询、更新操作之前。第一个请求先把数据插入防重表。后面的并发请求过来插入数据到防重表数据报错。捕获异常直接返回成功。

防重表设计:id+唯一索引。唯一索引可以是多个字段比如:name、code等组合起来的唯一标识,例如:zzh_01。而 mysql 中的 insert 操作,会对 (id+唯一索引) 附近的数据加上间隙锁。多个(id+唯一索引) 的数据并发进行入库时,变成了串行化操作。从而起到了防重的作用。

相关推荐
无休居士1 个月前
接口幂等性和并发安全的区别?
并发安全·幂等性
niceLiuSir2 个月前
提交保存,要做重复请求拦截,避免出现重复保存的问题
幂等性
微xinb08065 个月前
掌握RESTful API:从入门到精通,全面解析Web开发的基石!
前端·后端·api·restful·接口设计
柠檬茶五元5 个月前
get和post的区别,二者是幂等的吗?
运维·服务器·get·post·幂等性
路过秋天8 个月前
开源:Taurus.Idempotent 分布式幂等性锁框架,支持 .Net 和 .Net Core 双系列版本
幂等性
来自宇宙的曹先生8 个月前
哪些场景需要考虑到幂等性?
幂等性·分布式系统
我是一盘牛肉8 个月前
【从零开始学习重要知识点 | 第一篇】快速了解什么是幂等性以及常见解决方案
开发语言·学习·微服务·架构·幂等性
指挥部在下面1 年前
Rabbitmq消息重复消费问题(幂等性保障)
rabbitmq·幂等性·重复消费
tobebetter95271 年前
幂等性(防重复提交)
java·幂等性