高并发下库存总超卖？TP8.0 数据库悲观锁配合 Redis 原子队列【秒杀】-ThinkPHP-PHP中文网

tp8.0中单纯用select ... for update配合redis队列无法根治超卖，因两者未真正串联，存在竞态窗口；必须采用redis原子预减（decr）+db最终校验的组合方案。

高并发下库存总超卖？tp8.0 数据库悲观锁配合 redis 原子队列【秒杀】

直接说结论：TP8.0（ThinkPHP 8.0）中单纯用数据库 SELECT ... FOR UPDATE 配合 Redis 队列，**无法根治超卖**——因为两者没真正串起来，中间存在竞态窗口。

TP8.0 的事务默认不是长连接生命周期绑定的，Db::transaction() 块外一旦释放连接，锁就自动释放；更常见的是开发者在事务块里只查库存、没立刻扣减，而是先返回给业务层做判断再进另一段逻辑，此时锁早已释放，后续 UPDATE 变成无锁裸操作。

TP8.0 默认使用 PDO，默认隔离级别是 REPEATABLE READ，但 FOR UPDATE 只在当前事务内有效，事务一提交锁就丢
如果用了连接池或短连接（如 Swoole 长连接未显式复用），FOR UPDATE 可能根本没生效——查完就断连，锁形同虚设
没显式调用 Db::startTrans() + Db::commit() / Db::rollback()，仅靠闭包事务，异常时可能不回滚，导致锁残留或漏锁

Redis 队列（比如用 LPUSH 接收请求、LPOP 消费）只能控制「进入处理队列」的请求数，但不能保证「出队后扣库存」这一步原子。只要出队后的业务逻辑包含“读库存 → 判断 → 扣减”三步，就仍有超卖风险。

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

LPOP 是原子的，但取出来的只是个信号，不代表库存真够；你得再查一次 Redis 或 DB，而这次查又没锁
若队列长度设为 100，但第 100 个消费者和第 101 个几乎同时出队，且都看到库存剩 1，就必然超卖
TP8.0 的 Redis 封装（Cache::store('redis')）默认不提供带阻塞/超时的 BRPOP，手动用 Redis::lPop() 轮询会放大竞争

不要让数据库锁承担“第一道防线”职责，它只做最终一致性兜底。核心是把“库存判断+预占”压到 Redis 单命令里，DB 只负责落库和对账。

用 DECR 原子递减 Redis 库存 key：$left = Redis::decr('stock:1001');，返回值 ≤ 0 表示售罄，直接拒绝
只有 $left >= 0 才允许继续走订单创建流程，此时 Redis 已完成“预占”，其他并发请求会被 DECR 拦在门外
DB 层下单时仍需 SELECT stock FROM goods WHERE id = 1001 FOR UPDATE + UPDATE ... SET stock = stock - 1，不是为了防超卖，而是防止 Redis 异常丢失导致的“少扣多发”，即对账兜底
TP8.0 中记得用 Db::raw('stock - 1') 写 UPDATE，避免 PHP 层读-改-写造成二次竞争

很多团队卡在“看起来逻辑对，但压测还是超卖”，问题往往藏在这三处：

Redis 库存 key 没初始化或初始值错：比如用 SET stock:1001 100，但没加 EX 过期，缓存击穿后 key 消失，DECR 返回 null 被当 0 处理，直接放行
DB 事务没包裹完整链路：从 Redis 预减成功，到 DB 插入订单、扣库存、更新销量，必须在一个 Db::transaction() 里，否则 Redis 减了、DB 失败，库存就永久少 1
没处理 Redis 网络超时：TP8.0 的 Redis::decr() 抛异常时，没回滚已减的 Redis 值（虽然 DECR 本身不会失败，但网络断开会导致返回 false），建议加 try/catch + INCR 补偿