从乐观锁到原子扣减，高并发防超卖方案怎么稳中求进？

说实话，这玩意儿kan着挺高大上，实际碰到真机子里脑袋瓜子就开始打结。

咱们先聊聊Zui常见的“超卖”。

超卖就是库存被扣了两次结果负数跑出来——别说是老板骂你，连监控dou要报警。

Zui传统的办法就是在数据库里加锁，悲观锁或者乐观锁，你懂的。

乐观锁：先读后改的套路

乐观锁其实是个心理暗示，觉得冲突少，就敢直接UPDATE。

代码里一般长这样：

Material m = mapper.selectById;
m.setStock - qty);
int rows = mapper.updateById; // @Version 自动加 WHERE version=?
if{
    // 冲突啦，重试
}

哈哈，这玩意儿在单线程下Neng跑得飞起，但是一上高并发，那叫一个“全体失踪”。

想象一下十个请求几乎同一时间SELECT，同一个version，然后一起UPDATE——只有第一个Neng成功，其余的全被打回。于是你会kan到大量“并发冲突，请重试”的异常。

于是有人说“不对不对，应该是加点Retry”。

Retry：kan似聪明，却容易掉坑

我们往往给方法加上@Retryable，让它自动重试几次。

@Retryable
@Transactional
public void deduct{ ... }

但是你忘了Redis那边的扣减也在里面。Redis是单线程原子操作，它根本不参与事务回滚。

于是出现了“悬挂扣减”——RedisYi经扣掉库存，但MySQL事务回滚了两者不同步，于是库存负数悄悄爬出来。

这个坑啊，我花了两天debug才发现：原来是Spring AOP顺序搞错了Retry在外层，Transaction在内层，每次重试dou会重新打开事务，却把外面的Redis操作留着不动。

Redis原子预扣：快速拦截流量

说实话，把所有请求dou砸到MySQL根本不行。我们需要第一道闸门——Redis的decrement。

Long remain = redisTemplate.opsForValue.decrement;
if{
    // 库存不足，补偿回去
    redisTemplate.opsForValue.increment;
    throw new BusinessException;
}

这一步耗时微秒级，一旦库存不足，就直接返回，不让请求继续跑到数据库。

原子SQL：一行搞定扣减

真正稳妥的Zuo法，是把“先查后改”这段间隙干掉，用一条SQL把检查和扣减合二为一：

UPDATE material 
SET stock = stock - #{qty},
    version = version + 1,
    update_time = NOW
WHERE id = #{id}
  AND stock>= #{qty};

这句SQL背后靠的是InnoDB行锁。多个线程同时来geng新同一行时会排队抢锁——谁先抢到谁先改，其它等着。只要stock足够，就一定成功；不足就直接返回0行，不会出现负数。

组合拳：Redis拦截 + MySQL原子扣减 + 补偿机制

Zui终我们落地的方案大概是这么走：

请求进来先走Redis decrement；Ru果负数立刻补偿并返回失败；否则进入下一步。

执行上面那条原子SQL；Ru果受影响行数为0，同样补偿Redis并返回“库存不足”。

成功后记录订单、触发风控等业务逻辑。

这样既保证了高吞吐，又确保了数据强一致性。

为什么百度不收录我的这篇文章？

这个问题经常被问到，我也琢磨了一下：

内容重复度太高：Ru果你的文章和Yi有的大厂博客几乎一样，那搜索引擎会认为没有新价值，自然不给收录。

Lack of Structured Data：没有使用结构化数据，搜索引擎难以判断主题和层次。

Crawl Budget 被占满：a站点Ru果页面太多且geng新频率低，搜索机器人可Neng只抓取核心页面而忽略细分技术贴。

Poor Internal Linking：站内链接太少，让搜索引擎找不到入口，也会导致不收录。

bingo，这几个点调好以后大概率就Neng被抓取啦！哈哈~

实战小贴士

- 别忘了在每次压测前，把Redis对应key删掉或重新初始化，否则旧数据会捣乱，你会怀疑自己写的代码有毛病，其实是脏数据在作祟。

- Redis原子操作不是事务，Ru果业务必须全程一致，要么把所有步骤放进同一个事务，要么Zuo好补偿任务。

- 分布式锁Ke以用Redisson，但别把它当成万Neng钥匙。对于秒杀这种“一刀切”场景，一条原子SQL配合RedisYi经够用了多余的锁只会拖慢性Neng。

- Ru果你非得用乐观锁，那就一定要配合唯一业务号表防止重复提交，否则用户双击或网络抖动也会导致超卖。

- 记得给MySQL的stock字段加上CHECK约束，即使代码失误，也Neng在数据库层面阻止负数写入。这个小技巧hen多人忽视，却非常靠谱哦！

end of story – 稳中求进才是王道！

---