黑马程序员Redis入门到实战教程，深度透析redis底层原理+redis分布式锁+企业解决方案+黑马点评实战项目
总时长 42:48:00 共175P
此文章包含第52p-第p53的内容
文章目录
- 问题演示
- 使用jmeter测试两百个并发请求
- 超卖的原因分析
- 解决方案 加锁
- 悲观锁介绍
- 乐观锁介绍
- 乐观锁的两种方法-版本号法
- 乐观锁的两种方法-cas法
- 修改代码解决超卖
- 第一种方案 修改mybatis-plus的sql让库存等于之前查到的才可以修改
- 测试
- 第二种方案 修改mybatis-plus的sql让库存大于0才可以修改
- 测试
- 总结
问题演示
使用jmeter测试两百个并发请求
我们设置初始库存为100，测试请求200个 预期失败50%，这里我们发现失败率是45%，库存变成了-9，发生了超卖问题
卖出109件
超卖的原因分析
正常的流程
超卖的流程
解决方案 加锁
悲观锁介绍
悲观锁是会串行执行，性能不好，高并发场景下不适合
乐观锁介绍
乐观锁 只是在修改之前看一下之前的库存跟现在是否有区别，有区别代表在我之前有人已经修改了
乐观锁的两种方法-版本号法
版本号法
乐观锁的两种方法-cas法
cas法 不使用版本号 直接用库存进行判断就行
修改代码解决超卖
第一种方案 修改mybatis-plus的sql让库存等于之前查到的才可以修改
这么修改sql方法即可
测试
我们设置初始库存为100，测试请求200个 预期失败50%，这里我们发现失败率是89.9%，库存变成了79，虽然没有超卖，但是失败率大大提升，成功率太低
第二种方案 修改mybatis-plus的sql让库存大于0才可以修改
这里我们可以修改sql 让库存大于0才可以进行修改
测试
我们设置初始库存为100，测试请求200个 预期失败50%，这里我们发现失败率也是50%，库存变成了0，完美达到了预期效果
总结
也可以使用分段锁 将100个库存分到10张表里，这样相当于10个人同时抢，成功率提升10倍
