记一次项目中解决 -- 并发减库存超卖问题过程(Java)

起因：项目中要做预约功能，首先每天的余票都是有上限的，自然不能出现超卖的情况

基于我们项目是单体分布式的springcloud部署，我想了下

第一种方法，直接mysql加行锁，要update这条库存数据时，在数据库表层面加上行锁，直接禁止其他线程读写，就确保了这条库存数据是被单线程操作的，不会出现超卖

第二种方法，把库存数据放Redis，需要update时对缓存数据加锁，也能保证该条库存数据被单线程操作

第三种方法，是最简单的方法，代码实现悲观锁，也是最不专业的方法，就是在最终修改库存的方法添加同步代码块，没错就是他，就是sync，更新库存的方法单独封装成一个同步方法。但是这里有一点谨记，在同步代码块所在的方法类上千万别添加@Transactional注解，这个坑同样会造成超卖，因为，事务注解的操作范围大于同步代码块，你想有种情况：正在卖第十部手机锁释放但事务未提交，这时新线程进入查出老库存，又会把第十部手机再重复卖一次，老板会打爆你的狗头的，记住去掉@Transactional注解。（第三个方法完全可以采用）

第四种方案：代码加持在数据库层面实现乐观锁，听起来很复杂，其实不然。其实就是在数据库为每条库存数据添加唯一版本号version字段，查出来version是1，我更新的时候就加上这个version的 where 条件去更新(切记库存的加减和version新增在sql层面编写)，version相同我才更新库存，不相同不更新（这里根据update的sql返回值是否为1判断是否更新成功即可），再重新循环查一次最新version即可（第四种方案不仅适用于单机，若你们项目时集群部署同样是适合的，而且高效，代码也简单）

选择与思考：

第三种用户体验不会特别好，而且只适用于单机部署的项目

个人比较推荐第四种乐观锁方案，代码也简单

后期如果并发特别大，有的线程由于等太久导致请求超时，需要考虑做做接口限流。
————————————————
版权声明：本文为CSDN博主「文件传输管理助手」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_40083307/article/details/118059978