结合案例、列举场景的接口幂等性设计方案。
方案 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+唯一索引) 的数据并发进行入库时,变成了串行化操作。从而起到了防重的作用。