【黑马点评日记】高并发秒杀：库存超卖与锁机制解析

个人主页北极的代码欢迎来访作者简介java后端学习者❄️个人专栏苍穹外卖日记SSM框架深入JavaWeb✨命运的结局尽可永在不屈的挑战却不可须臾或缺前言我们之前学习完了优惠卷秒杀的简单实现而使用场景仅仅是我们自己测试的时候在现实生活中优惠卷秒杀同一时间可能会有成百上千的人同时点击这时就会导致一系列的问题这里我们具体讲解。摘要本文探讨了高并发环境下优惠券秒杀系统面临的库存超卖问题及其解决方案。通过模拟200线程抢购100张优惠券的场景发现数据库库存出现负值-9订单数量异常109。原因在于线程竞争导致并发查询和扣减不同步。文章对比了两种主流解决方案1悲观锁for update通过独占锁确保数据一致性但性能较低2乐观锁基于版本号或库存值利用CAS机制实现无锁并发性能更优但存在失败率此外还列举了6种扩展方案包括Redis原子操作、消息队列削峰等。最终建议秒杀场景优先采用乐观锁配合Redis预扣减平衡性能与数据一致性。库存超卖问题我们先模拟一下假设有200个线程代表200个用户同时去抢100张优惠卷看看会得到什么结果。按照正常来说200个人抢100张优惠卷那么肯定是会成功一般的也就是还有100人没抢到优惠卷。但是查看结果时发现我们数据库表中的库存变成-9订单数量变成了109。这在实际场景中时完全不允许的。为什么会出现这种问题呢如图所示在高并发的环境下线程之间是竞争的关系往往是一个还没完全执行完就会进入其他的线程了。如图我们在执行线程1时原来库存还剩一个查询库存得到1此时线程2进来了也查询库存由于线程1还没执行完扣减操作所以线程2查询操作得到的库存也是1之后经过两次扣减此时我们的库存就变成了-1这仅仅是两个线程如果更多那么产生的后果可能更严重。超卖问题的解决方案1. 悲观锁不相信其他人不会同时改数据所以每次操作前先主动把数据锁起来不让别人动。悲观锁认为每次操作数据时都很可能有其他线程同时修改。因此它在操作前就先“锁住”数据让自己独占等操作完成后再释放。就像去洗手间先锁上门里面的人用完出来下一个人才能进。标准语法MySQLsql -- 普通查询 select * from seckill_voucher where voucher_id 1; -- 加悲观锁的查询就在后面加 for update select * from seckill_voucher where voucher_id 1 for update;实现方式在SQL中使用for updatesql -- 查询库存时加行锁for update select stock from seckill_voucher where voucher_id ? for update; -- 判断库存扣减库存 update seckill_voucher set stock stock - 1 where voucher_id ?;在Java代码中的典型实现使用Transactional加同步锁或直接在SQL层面控制java Transactional public Result seckillVoucher(Long voucherId) { // 1. 使用for update加悲观锁查询 SeckillVoucher voucher seckillVoucherMapper.selectForUpdate(voucherId); // 2. 判断库存是否充足 if (voucher.getStock() 0) { return Result.fail(库存不足); } // 3. 扣减库存 boolean success seckillVoucherMapper.decreaseStock(voucherId); if (!success) { return Result.fail(扣减库存失败); } // 4. 创建订单... return Result.ok(); }缺点性能较差同一时间内只有一个线程能处理并发能力低。举例1. 假设有一张秒杀券表简化版sqlCREATE TABLE seckill_voucher ( voucher_id INT PRIMARY KEY, stock INT );数据举例voucher_idstock1001102. 正常情况下无锁两个用户同时来买用户A查询库存 → 发现是 10用户B查询库存 → 发现也是 10用户A库存 10 0 → 改成 9用户B库存 10 0 → 改成 9结果卖了 2 件库存只减少 1 件 →超卖3. 使用悲观锁for update后用户Asql-- 1. 先锁住这条记录 select stock from seckill_voucher where voucher_id 1001 for update; -- 此时这行数据被“行锁”锁住 -- 其他所有事务必须等待用户Bsql-- 也尝试锁同一行 select stock ... for update; -- 会被阻塞必须等 A 释放锁用户Asql-- 判断库存 → 扣减 update seckill_voucher set stock stock - 1 where voucher_id 1001; -- 提交事务释放锁 commit;用户Bsql-- 此时才拿到锁看到的是最新库存9 -- 继续判断、扣减结果一次只允许一个人改 →不会超卖2. 乐观锁乐观锁认为数据冲突的概率较低所以不主动加锁而是在更新时检查数据是否被其他线程修改过。一般通过版本号或库存值本身来判断。就像更新文档先复制一份出来改保存时看服务器上的版本有没有变化如果没变就成功保存如果变了就重试或失败。实现方式一基于版本号实现方式二基于库存值CAS法sql -- 扣减时检查库存是否还是之前查到的数值 update seckill_voucher set stock stock - 1 where voucher_id ? and stock old_stock;其实就是把看版本号的变化的判断条件变成了库存本身。java Boolean success iSeckillVoucherService .update() // 1. 开始构建更新操作 .setSql(stock stock - 1) // 2. 设置要更新的字段 .eq(voucher_id, voucherId) // 3. 条件1指定哪个商品 .gt(stock, 0) // 4. 条件2库存必须大于0乐观锁核心 .update(); // 5. 执行更新一、这段代码对应什么SQLMyBatis-Plus 会帮我们自动生成以下SQLsql update seckill_voucher set stock stock - 1 where voucher_id ? and stock 0 -- 这是乐观锁的关键注意代码里的.gt(stock, 0)就是where stock 0二、乐观锁是怎么防止超卖的核心原理CASCompare And Swap比较并交换更新时检查库存是否还是原来的值或满足条件如果满足才更新。正常情况一人购买sql -- 原始库存stock 10 -- 用户A执行update update seckill_voucher set stock 9 where voucher_id 1 and stock 0; -- 10 0 ✅ 条件成立 -- 受影响行数1更新成功 -- 库存变成9并发情况两人同时购买sql -- 原始库存stock 10 -- 用户A和用户B同时执行时间差微乎其微 -- 假设A先到达数据库 -- 用户A update seckill_voucher set stock 9 where voucher_id 1 and stock 0; -- ✅ 成功受影响行数1stock变成9 -- 用户B update seckill_voucher set stock 9 where voucher_id 1 and stock 0; -- 现在stock99 0 ✅ 条件也成立 -- ✅ 也成功受影响行数1stock变成8 -- 结果卖出2件库存从10→8✅ 正确极端并发库存为1时sql -- 原始库存stock 1 -- 用户A、B、C三个人同时抢假设同时到达数据库 -- 数据库内部串行执行 -- 用户Awhere stock 010 ✅→ 成功stock变成0 -- 用户Bwhere stock 000 ❌→ 失败受影响行数0 -- 用户Cwhere stock 000 ❌→ 失败受影响行数0 -- 结果只卖出1件库存从1→0✅ 没有超卖两种写法的对比对比项stock 旧值stock 0检查粒度精确到具体数值只检查范围并发成功率低每人旧值不同高只要0就能抢实现复杂度需要先查询一条SQL搞定适用场景库存可增可减库存只减不增三、代码中怎么判断成功还是失败java Boolean success iSeckillVoucherService .update() .setSql(stock stock - 1) .eq(voucher_id, voucherId) .gt(stock, 0) .update(); // update() 方法返回 boolean // - true更新成功至少有一行被修改 // - false更新失败没有行被修改说明库存不足 if (!success) { return Result.fail(库存不足抢购失败); } // 成功继续创建订单...实际上update()返回的是java // MyBatis-Plus 的 update() 底层 // 受影响行数 0 返回 true // 受影响行数 0 返回 false四、这种乐观锁的优缺点✅ 优点优点说明无需加锁不会阻塞其他请求性能高实现简单一行.gt(stock, 0)就搞定无死锁风险因为是单条update语句适合高并发数据库能处理大量并发更新❌ 缺点缺点说明会有失败库存为1时100人抢只有1人成功99人失败不适合激烈竞争大量请求会失败浪费数据库资源不能保证每次都成功用户体验可能不好提示重试在Java代码中的典型实现配合重试机制java Transactional public Result seckillVoucher(Long voucherId) { // 1. 查询原始库存 SeckillVoucher voucher seckillVoucherMapper.selectById(voucherId); Integer oldStock voucher.getStock(); // 2. 判断库存 if (oldStock 0) { return Result.fail(库存不足); } // 3. 乐观锁扣减只有stock oldStock时才成功 int updateCount seckillVoucherMapper.decreaseStockWithCAS(voucherId, oldStock); if (updateCount 0) { // 说明数据被修改过扣减失败 return Result.fail(抢购失败请重试); } // 4. 创建订单... return Result.ok(); }Mappper中的SQLjava Update(update seckill_voucher set stock stock - 1 where voucher_id #{voucherId} and stock #{oldStock}) int decreaseStockWithCAS(Long voucherId, Integer oldStock);对比总结特性悲观锁乐观锁核心思想先锁后操作更新时检查版本数据库实现select ... for updateupdate ... where stock ?优点数据强一致简单可靠并发性能高无阻塞缺点并发性能低可能死锁冲突时需重试可能失败适用场景高冲突、临界区短的场景低冲突、读多写少的场景在黑马点评中的应用后台管理等低并发场景秒杀、抢购等高并发场景总结在实际秒杀场景中通常优先推荐乐观锁因为秒杀场景下读库存的次数远多于写库存乐观锁不会阻塞大量并发请求配合Redis预扣减库存可以极大减少数据库压力如果需要保证100%不超卖且可以接受低吞吐量则使用悲观锁。解决超卖的其他思路方案1唯一索引防重思路不让超卖发生而是让重复购买直接失败sql -- 订单表加唯一约束 ALTER TABLE voucher_order ADD UNIQUE INDEX uk_user_voucher (user_id, voucher_id); -- 用户重复下单会直接报错不会超卖优点数据库级别保证绝不超卖缺点只能防止同一用户重复买不能防止多个用户抢最后一个方案2Redis原子递减 异步落库思路在Redis里扣减库存成功了再去数据库创建订单java // 1. Redis原子操作 Long stock redisTemplate.opsForValue().decrement(stock: voucherId); if (stock 0) { // 库存不足加回去 redisTemplate.opsForValue().increment(stock: voucherId); return 抢购失败; } // 2. 异步发送消息慢慢落库 rabbitTemplate.convertAndSend(orderQueue, voucherId);优点性能极高10万级QPS缺点可能丢失订单需要补偿机制方案3消息队列削峰填谷思路所有请求先进队列消费者一个一个处理java // 1. 请求进来先进队列 boolean success queue.offer(request); if (!success) { return 系统繁忙请稍后重试; } // 2. 消费者单线程处理 RabbitListener(queues seckillQueue) public void handle(SeckillRequest request) { // 这里就不会有并发问题了 synchronized (this) { // 扣减库存、创建订单 } }优点彻底解决并发问题流量可控缺点延迟增加用户体验下降方案4令牌桶限流 超卖检测思路限制进入的人数让超卖不可能发生java // 1. 限流每秒只放100个请求进去 RateLimiter limiter RateLimiter.create(100); public Result seckill(Long voucherId) { // 拿不到令牌直接拒绝 if (!limiter.tryAcquire()) { return Result.fail(太火爆了请稍后再试); } // 2. 这里只有100个人能进来 // 乐观锁扣减库存 boolean success update().gt(stock, 0).update(); return success ? Result.ok() : Result.fail(库存不足); }优点保护系统不被冲垮缺点限流值需要精确估算否则会误杀或漏杀方案5提前预分配库存分段库存思路把库存分成N段每段独立扣减java // 假设1000个库存分10个段每段100个 // 用户请求进来hash到不同的段 int segmentId userId % 10; String segmentKey stock:segment: segmentId; // 每个段独立扣减 Long stock redisTemplate.opsForValue().decrement(segmentKey);优点锁粒度更细并发度提升N倍缺点可能出现段1卖完段2还有的局面方案6CAS无锁编程Java层面思路用AtomicInteger在JVM里做库存扣减java // 适用场景单机、库存不大 private AtomicInteger stock new AtomicInteger(10); public Result seckill() { // CAS操作原子性 int oldValue stock.get(); while (oldValue 0) { if (stock.compareAndSet(oldValue, oldValue - 1)) { return Result.ok(抢购成功); } oldValue stock.get(); } return Result.fail(库存不足); }优点无锁性能极高缺点只适用于单机分布式不适用完整对比表方案适用场景性能复杂度是否超卖数据库悲观锁低并发、强一致性低低❌ 不会数据库乐观锁中并发、冲突少中低❌ 不会Redis原子操作高并发、可接受少许失败极高中⚠️ 可能丢失消息队列超高并发、不要求实时高高❌ 不会限流 乐观锁保护系统、流量可控高中❌ 不会分段库存超高并发、库存分散极高高❌ 不会JVM CAS单机、库存较小极高低❌ 不会结语如果对你有帮助请点赞关注收藏你的支持就是我最大的鼓励