TP8.0 高并发下库存超卖？Redis 原子递减结合数据库乐观锁控制

高并发场景下的库存超卖，一直是秒杀系统的“老大难”。TP8.0 要防住这个问题，光靠 MySQL 行锁扛不住瞬时洪峰，纯 Redis 操作又没法跟数据库事务完美对齐——必须让 Redis 的原子预扣减和数据库的乐观锁形成一套闭环校验，才能既挡住流量，又保证最终一致性。

第一步：Redis 层原子预扣减（拦截绝大多数超卖）

在 ThinkPHP8.0 的控制器里，直接用 RedisTemplate 的 DECRBY 命令扣减库存键值。这个操作由 Redis 单线程保证原子性，完全不需要额外加锁。

执行 redis()->decrBy('stock:1001', $buyCount)，返回的是扣减后的剩余库存。如果返回值 【小于 0】，立即终止流程并返回“库存不足”，根本不用再往下走数据库层。

这一步必须前置——它能把 95% 以上的超卖请求挡在数据库外面，避免无效事务把 MySQL 压垮。

第二步：数据库层乐观锁校验与落库（兜底强一致）

只有 Redis 预扣成功（返回值 ≥ 0）之后，才发起数据库更新。

先查询当前商品记录，拿到最新的 stock 和 version 字段值。然后构造这样的 SQL 更新语句：UPDATE goods SET stock = stock - ?, version = version + 1 WHERE id = ? AND version = ? AND stock >= ?。

执行后检查影响行数：如果为 0，说明版本已被其他请求抢先修改，或者库存已经扣完——此时需要回滚 Redis（用 INCRBY 补回），并抛出业务异常；如果为 1，则提交事务、记录订单。

第三步：异常路径下的 Redis 库存自动回滚

方法一：在数据库更新失败的 catch 块中，显式调用 redis()->incrBy('stock:1001', $buyCount) 把预扣的量补回来。

方法二：用 TP8.0 的 Db::transaction() 包裹整个流程，但要注意——Redis 操作没法纳入数据库事务，必须手动补偿。

【务必在 try-catch 的 finally 或 catch 中执行回滚】，否则 Redis 库存会永久丢失，导致少卖。

第四步：Lua 脚本加固原子性（可选高阶防护）

把 Redis 预扣减与库存判断合并成一段 Lua 脚本执行，彻底避开网络往返中的竞态窗口。

脚本内容示例：if redis.call("get", KEYS[1]) >= ARGV[1] then return redis.call("decrby", KEYS[1], ARGV[1]) else return -1 end。

在 TP8.0 中通过 redis()->eval($lua, ['stock:1001'], [$buyCount]) 调用，返回新库存或 -1。

这一步不是必须的，但当 QPS 突破 5000+ 且 Redis 与应用间延迟波动较大时，它能消除最后一次“读-判-写”间隙，算是锦上添花的高阶防护。