ThinkPHP8.0锁表机制防止秒杀系统库存超卖实战详解

在此场景中，表锁（LOCK TABLES）与秒杀防超卖并无实际关联。真正能在高并发环境下保障库存准确性的，是 **InnoDB 行级悲观锁 + 事务**，且必须配合索引命中才能生效。 许多开发者初学时习惯使用 ThinkPHP 的 `lock(false)` 或直接执行 `LOCK TABLES`，结果导致整表被锁定，QPS 急剧下降——这种方法根本无法承受秒杀场景的冲击。 ### 为何 lock(false) 锁表不适合秒杀场景？ `lock(false)` 底层实现为 MySQL 的 `LOCK TABLES xxx WRITE`，属于表级写锁： - 所有读写请求（甚至包括查询其他商品的请求）都需排队等待，仅仅因为操作了一个商品 ID - 在秒杀峰值下，单表锁会使库存模块完全串行化，吞吐量直接归零 - ThinkPHP 6.1+ 已明确废弃字符串锁（例如 `lock('update')`），其行为不可控且实际并不生效 ### 正确方案：InnoDB 行锁 + 事务 + lock(true) `lock(true)` 本身不会自动加锁，只有在事务内、配合 `where()` 与 `find()` 一起使用时，才会真正生成 `SELECT ... FOR UPDATE` 语句，从而对目标行施加排他锁： - 表引擎必须为 InnoDB，且 where 条件字段（如 `id`）必须建有索引，否则行锁可能退化为表锁 - 锁的触发时机是在 `find()` 执行时，若将其放在 `update()` 之前则无效——因为 update 不经过 select，无法锁定行 - 事务需显式开启，推荐使用 `Db::transaction()` 包裹完整逻辑 ### 秒杀扣库存的标准代码示例 假设商品 ID 为 1001，需扣减 1 件库存： ```php Db::transaction(function () use ($goodsId, $num) { // 关键：lock(true) 必须紧跟 where() 之后、find() 之前 $goods = Db::name('goods') ->where('id', $goodsId) ->lock(true) ->find(); if (!$goods || $goods['stock'] < $num) { throw new Exception('库存不足'); } // 原子更新：WHERE 条件确保不会扣成负数 $result = Db::name('goods') ->where('id', $goodsId) ->where('stock', '>=', $num) // 防超卖二次校验 ->update(['stock' => Db::raw("stock - {$num}")]); if (!$result) { throw new Exception('库存已被抢完'); } }); ``` 注意：`where('stock', '>=', $num)` 是必要的兜底措施，防止锁失效或网络重试导致重复扣减。 ### 更高并发场景：建议叠加 Redis 预扣 纯数据库行锁适用于中等并发（数百至数千 TPS）。若需支撑万级 QPS，最好采用分层方案： - 秒杀开始前，通过 `LPUSH goods:1001 1` 将 100 个占位符推入 Redis List - 用户请求时直接执行 `LPOP goods:1001` —— 成功即获得资格，天然具备原子防超卖特性 - 预扣成功后，再异步进入队列完成最终下单及 DB 库存落库，DB 层仍需沿用上述行锁逻辑保障最终一致性