淘宝秒杀，库存能直接扣数据库？

秒杀是大型架构的核心，下面我重点详解淘宝秒杀@mikechen

淘宝秒杀

秒杀是淘宝/天猫在大促（双11、双12等），或日常活动中推出的高并发限时抢购玩法。

指定商品在极短时间内以超低价开卖，库存通常很少，瞬间涌入海量用户抢购。

库存极少：很多商品只有几十到几千件。

时间窗口极短：往往几秒到几分钟就抢完。

强一致性要求：不能超卖（卖出数量超过库存），也不能大量少卖。

库存能直接扣数据库？

假设商品库存只有 100 件，秒杀瞬间来了 100 万请求：

100万请求
    ↓
Nginx
    ↓
应用服务器
    ↓
MySQL
    ↓
UPDATE stock = stock - 1

即使 SQL 本身很简单：

UPDATE product
SET stock = stock - 1
WHERE id = 1001
  AND stock > 0;

MySQL 可以通过原子更新 + 行锁，保证不会轻易出现超卖。

但是问题在于：

100 万请求都跑到 MySQL，数据库会成为整个系统的瓶颈。

虽然数据库可以保证正确性，但这条热点库存记录会形成严重的行锁竞争。

最终表现为：

数据库连接池被占满；

大量线程阻塞等待锁；

数据库 CPU、IO 和日志压力增加；

订单、支付、后台管理等普通业务被连带影响；

大量已经注定失败的请求仍然进入数据库。

所以，数据库直接扣库存适合做最终落库，不适合承接全部秒杀请求。

因此，秒杀系统一般采用“先在缓存中预扣减，再异步落库”的方案。

以上