文章目录
- 一:什么是幂等性问题
- 二:什么原因导致幂等性问题?
- 三 :幂等性解决办法
一:什么是幂等性问题
幂等性是对于写操作来说的,一个写操作,不论重复执行多少次,结果总是一致的,例如:
一个接口
如果幂等,不管被调多少次,只要参数不变,结果也不变。
一个MQ消息,不论收到多少次,只有一个消息能执行,结果也是不变的。
二:什么原因导致幂等性问题?
-
底层
网络阻塞和延迟
的问题:- 网络原因导致客户端这里不能及时收到服务端的响应,这时候用户会重复点击、重复请求
- MQ中,客户端也有重试机制,如果投递失败或者超时,则会重新投递,对于服务端来说就会收到重复发过来的消息。RPC调用也是同理,都有重试机制。
-
用户层面
的重复操作:- 用户点击下单按键,在没有收到服务端响应之前,用户还可以重复去点击
- 用户人工强制退出或者App闪退,之后重新打开重新下单。
三 :幂等性解决办法
无非增删改查操作,一下分析基于接口幂等做出的分析。
-
全局唯一ID(通用方案)
根据业务的操作和内容生成一个全局ID,在执行操作前先根据这个全局唯一ID是否存在,来判断这个操作是否已经执行。
如果不存在则把全局ID,存储到Redis
。如果存在则表示该方法已经执行,在redis层面实现拦截。
题外话
:全局ID,保证唯一性即可。例如:uuid、雪花算法、业务字段+时间戳、业务本身的唯一约束。像接口的幂等:唯一ID可以选择方法名啊参数啊业务字段啊这些拼接形成,只要能唯一标识是*** 调用 ***接口即可。像MQ消息的唯一ID:可以选择唯一的业务字段啊等等来唯一标识此条消息即可。 -
去重表(唯一索引):针对
insert
这种情况是针对有唯一字段的插入操作,不如:一个订单只会支付一次,订单ID可以作为唯一标识,这时候可以去增加一张去重表,并且吧唯一标识作为唯一索引,实现上:在创建支付单据时将订单ID也写入去重表,放在一个事务中,如果重复创建,数据库会抛唯一索引异常,操作就会回滚,也就是一个订单只会支付一次。 -
插入或者更新(
InsertOrUpdate
)
这种方法插入并且有唯一索引的情况,比如我们要关联商品品类,其中商品的ID和品类的ID可以构成唯一索引,并且在数据表中也增加了唯一索引。这时就可以使用InsertOrUpdate操作。 -
版本号(
update
)
这种方法适合在更新的场景中,比如我们要更新商品的名字,这时我们就可以在更新的接口中增加一个版本号,来做幂
等:
boolean updateGoodsName(int id,String newName,int version);
实现上:
update goods set name=#{newName},version=#{version} where id=#{id} and version<${version}
- 状态机控制(
update
)
这种方法适合在有状态机流转
的情况下,比如就会订单的创建和付款
,订单的付款肯定是在之后,这时可以通过在设计状态字段时,使用int类型,并且通过值类型的大小来做幂等
,比如订单的创建为0,付款成功为2,付款失败为1。付款成功可以修改未付款的或者付款失败的,付款失败只能修改未付款的
update goods_order set status=#{status} where id=#{id} and status<#{status}