数据库锁方案

数据库锁方案是最直观的防超卖方案。库存存在数据库里，下单时用事务扣减库存，再创建订单。它的优点是正确性强，缺点是热点库存行会成为瓶颈。

本章主线

本章会依次分析：

1. 悲观锁：通过行锁串行扣减库存，正确但吞吐低。
2. 乐观锁：用版本号或条件更新减少锁等待。
3. 性能对比：理解数据库方案在高峰下的瓶颈。

防超卖核心

最基本的扣库存 SQL 应该带条件：

数据设计要点

• 这里关注数据模型和约束关系，不需要记住具体语法。

只有更新成功，才能继续创建订单。这样可以避免库存变成负数。

数据库方案的问题

数据库方案适合低并发抢购，但在秒杀高峰会遇到：

• 同一库存行被大量请求竞争。
• 失败请求也消耗数据库连接。
• 事务持有锁时间越长，吞吐越差。
• 数据库成为全链路最脆弱的核心依赖。

因此，数据库锁方案适合作为理解正确性的起点，不适合作为大规模秒杀的最终方案。

学完本章要回答

• 悲观锁和乐观锁分别解决什么问题？
• 为什么带条件更新能防止超卖？
• 为什么数据库正确但承受不了秒杀峰值？

下一章会把库存扣减前置到 Redis，并用队列削峰。