起因：项目中要做预约功能，首先每天的余票都是有上限的，自然不能出现超卖的情况
基于我们项目是单体分布式的springcloud部署，我想了下😁
第一种方法，直接mysql加行锁，要update这条库存数据时，在数据库表层面加上行锁，直接禁止其他线程读写，就确保了这条库存数据是被单线程操作的，不会出现超卖
第二种方法，把库存数据放Redis，需要update时对缓存数据加锁，也能保证该条库存数据被单线程操作
第三种方法，是最简单的方法，代码实现悲观锁，也是最不专业的方法，就是在最终修改库存的方法添加同步代码块，没错就是他，就是sync，更新库存的方法单独封装成一个同步方法。但是这里有一点谨记，在同步代码块所在的方法类上千万别添加@Transactional注解，这个坑同样会造成超卖，因为，事务注解的操作范围大于同步代码块，你想有种情况：正在卖第十部手机锁释放但事务未提交，这时新线程进入查出老库存，又会把第十部手机再重复卖一次，老板会打爆你的狗头的，记住去掉@Transactional注解。（第三个方法完全可以采用）
第四种方案：代码加持在数据库层面实现乐观锁，听起来很复杂，其实不然。其实就是在数据库为每条库存数据添加唯一版本号version字段，查出来version是1，我更新的时候就加上这个version的 where 条件去更新(切记库存的加减和version新增在sql层面编写)，version相同我才更新库存，不相同不更新（这里根据update的sql返回值是否为1判断是否更新成功即可），再重新循环查一次最新version即可（第四种方案不仅适用于单机，若你们项目时集群部署同样是适合的，而且高效，代码也简单）
选择与思考：
第三种用户体验不会特别好，而且只适用于单机部署的项目
个人比较推荐第四种乐观锁方案，代码也简单
后期如果并发特别大，有的线程由于等太久导致请求超时，需要考虑做做接口限流。