网站秒杀活动库存扣减后端高并发实现方案

秒杀活动的核心难题在于高并发下库存扣减的准确性。用户抢购时，如果后端处理不当，会出现超卖（卖出比库存多）或少卖（库存明明还有却显示售罄）的情况。这直接关系到活动成败和用户体验。解决这个问题的关键在于选择正确的扣减策略和保证数据一致性。

库存扣减为什么容易超卖

很多开发者刚接触秒杀时，习惯用“先查库存再扣减”的逻辑。比如用户下单时，先读数据库库存数量，判断大于0就执行update语句减1。但在高并发场景下，多个请求同时读到库存为1，都认为可以扣减，最终实际扣减次数超过库存数，这就是超卖。

根本原因是查询和更新之间存在时间差，这个时间差在高并发下被放大。即便在查询语句上加锁，也只能串行化处理，性能急剧下降。更糟糕的是，如果使用MySQL的行锁，秒杀流量一上来，数据库连接池瞬间被占满，系统直接瘫痪。

真正的解法是让扣减操作原子化。直接执行UPDATE stock SET quantity = quantity - 1 WHERE product_id = ? AND quantity > 0。这条SQL利用数据库自身的行锁和条件判断，一条语句就能完成判断库存、扣减库存两个动作，不存在时间差。执行后检查受影响行数，如果为0说明库存不足，返回失败。这是最基础也是最可靠的方案。

高并发下如何保证性能与一致

单靠数据库扣库存虽然正确，但扛不住秒杀级别的流量。几万人同时抢100件商品，数据库会被打爆。因此必须引入缓存层做流量削峰。

常用的做法是使用Redis的原子操作。Redis单线程处理命令，天然支持原子性。用DECR或Lua脚本扣减库存。例如在Lua脚本中先判断库存是否大于0，大于则扣减并返回成功，否则返回失败。这个脚本在Redis中原子执行，彻底杜绝超卖。

但Redis扣减后，最终还是要同步到数据库做持久化。难点在于如何保证Redis和数据库的数据最终一致。我的做法是：Redis预扣库存，扣减成功后允许用户下单；订单异步写入消息队列，后台消费队列消息，更新数据库库存。如果数据库更新失败，需要做补偿机制，比如回滚Redis库存。

另外要注意库存预热。秒杀开始前，把数据库中的库存数一次性加载到Redis，设置好过期时间。活动期间直接操作Redis，活动结束后再异步回写数据库。这样可以限度减少数据库压力。

秒杀系统的库存扣减，没有银弹。核心是选择原子扣减策略，配合缓存和消息队列做分层处理。不要追求完美的一致性，而是要在性能和正确性之间找到平衡点。对于99%的业务场景，Redis预扣加数据库最终一致就是最佳方案。