业务场景分析
用户购买商品的逻辑中,需要对用户钱包的余额进行查询和扣款
异常:如果同一用户并发执行多个业务进行”查询+扣款”的业务中有一定概率出现数据不一致
Tips:如果没有做限制单一接口请求频率,用户使用并发请求的手段也有概率出现数据不一致
扣款场景
Step1: 从数据库查询用户钱包余额
Step2: 业务逻辑
Tips: 文章分享处理同一用户并发扣款一致性,检查库存啥的逻辑略过
1、 查询商品价格,比如70元 2. 商品价格对比余额是否足够,足够时进行扣款提交订单逻辑
Step3: 将数据库的余额进行修改
在没有并发的情况下,这个流程没有任何问题,原有余额100,购买70元的商品,剩余30元
异常场景
Step1: 用户并发购买业务A和业务B(不同实例/服务),一定概率并行查询余额是100
Step2: 业务A和业务B分别扣款逻辑处理,业务A商品70结果余额30,业务B商品80结果余额20
Step3:
1 业务A先进行修改,修改余额为30
2 业务A后进行修改,修改余额为20
此时异常出现了,原余额100元,业务A和业务B的商品价格总和150元(70+80)都购买成功且余额还剩20元。
异常点:业务A和业务B并行查询余额为100
解决方案
悲观锁
使用Redis悲观锁,例如抢到一个KEY才能继续操作,否则禁止操作
封装了一个开箱即用的RedisLock
乐观锁
使用CAS(Compare And Set)
在set写回的时候,加上初始状态的条件compare,只有初始状态不变的时候才允许set写回成功,保证数据一致性的方法
将:
改为:
这样的话并发操作时只有一个是执行成功的,根据affect rows是否为1判断是否成功
结语
解决方案有很多,这只是其中一种解决方案
使用Redis悲观锁的方案会降低吞吐量