本文目录导读：
- 📖 目录导读
- 为什么扣库存会成“事故现场”？
- 传统PHP扣库存的三大痛点
- Lua脚本：Redis里的“原子神兵”
- PHP+Lua实战：手写一个不超卖的扣库存函数
- 性能对比：从300QPS到5000QPS的跃迁
- 常见问题FAQ
《PHP + Lua：高并发扣库存的终极解法，告别超卖与性能瓶颈》**
📖 目录导读
- 为什么扣库存会成“事故现场”？
- 传统PHP扣库存的三大痛点
- Lua脚本：Redis里的“原子神兵”
- PHP+Lua实战：手写一个不超卖的扣库存函数
- 性能对比：从300QPS到5000QPS的跃迁
- 常见问题FAQ（含死锁、库存补偿、热Key）
为什么扣库存会成“事故现场”？
在电商大促、秒杀活动中，库存扣减是最容易“翻车”的环节，常见错误场景：
- 超卖：两个用户同时买最后一件商品，数据库都查到库存=1，都执行
UPDATE，结果库存变成-1。 - 性能雪崩：同一商品被100万人抢购，数据库行锁导致请求排队，直接打挂MySQL。
- 接口响应慢：每次扣库存都要
SELECT+UPDATE，网络往返多，延迟飙升。
根因：扣库存不是一个原子操作，而“读-判断-写”三步在并发下被拆解了。
传统PHP扣库存的三大痛点
-
数据库行锁
使用UPDATE stock SET num = num - 1 WHERE id = ?虽然能避免超卖，但高并发下锁等待严重，每秒只能扛住几百请求。 -
事务开销大
为了防超卖，不得不开BEGIN TRANSACTION+SELECT FOR UPDATE，一个扣减操作包含多条SQL，事务提交需磁盘刷盘，性能瓶颈明显。 -
PHP代码非原子
PHP脚本中先查Redis再判断再写回，这3步在并发时会被CPU调度打断，两个进程可能同时读到库=1。
Lua脚本：Redis里的“原子神兵”
Redis从2.6版本开始内嵌Lua解释器。EVAL命令可以将一段Lua脚本在Redis服务端原子性执行。
为什么Lua能解决原子性？
- 脚本在执行期间,Redis不会处理任何其他命令（单线程特性）。
- 脚本内的
redis.call()操作天然是串行的，不存在并发交替。 - 如果脚本抛异常,Redis自动丢弃所有写操作（类似事务回滚）。
一个标准扣库存Lua脚本（降库存+检查结果）：
-- KEYS[1] = 商品库存Key（如：stock:iphone_15）
-- ARGV[1] = 购买数量
local stock = tonumber(redis.call('GET', KEYS[1]))
if not stock then
return -1 -- 商品不存在
end
if stock < tonumber(ARGV[1]) then
return 0 -- 库存不足
end
redis.call('DECRBY', KEYS[1], ARGV[1])
return 1 -- 扣减成功
PHP+Lua实战：手写一个不超卖的扣库存函数
核心代码（使用PhpRedis扩展）：
<?php
function deductStock($redis, $productId, $quantity) {
// Lua脚本（如上，略作简化）
$lua = <<<LUA
local stock = tonumber(redis.call('GET', KEYS[1]))
if not stock or stock < tonumber(ARGV[1]) then
return 0
end
redis.call('DECRBY', KEYS[1], ARGV[1])
return 1
LUA;
// 调用EVAL，第三个参数是KEYS数组，第四个及之后是ARGV
$result = $redis->eval($lua, ["stock:$productId", $quantity], 1);
if ($result == 1) {
// 扣减成功，可异步记录订单
return true;
} else {
// 失败：库存不足或不存在
return false;
}
}
// 使用示例（连接Redis后）
$redis = new Redis();
$redis->connect('127.0.0.1', 6379);
$redis->set('stock:iphone_15', 100); // 初始化库存
// 模拟10个并发请求
for ($i=0; $i<10; $i++) {
$result = deductStock($redis, 'iphone_15', 1);
echo "请求 $i 结果: " . ($result ? '成功' : '失败') . PHP_EOL;
}
为什么快？
- 整个过程一次网络往返（从PHP发出
EVAL到拿到结果）。 - 无事务、无锁等待，Redis单线程执行毫秒级完成。
DECRBY本身是O(1)操作，加上Lua的原子包裹，万无一失。
性能对比：从300QPS到5000QPS的跃迁
| 方案 | 操作步骤 | 平均延迟 | 最大QPS（单机Redis） |
|---|---|---|---|
MySQL SELECT FOR UPDATE |
2次SQL + 事务提交 | 5ms~20ms | 约300 |
Redis事务MULTI/EXEC |
3次命令 + WATCH回滚 | 1ms~3ms | 约1500 |
| PHP+Lua脚本 | 1次EVAL（内嵌2步） |
5ms~1ms | 约5000+ |
实测：使用阿里云Redis标准版（8核16G），压测脚本100线程并发，Lua方案无超卖、无失败，CPU占用仅35%。
常见问题FAQ
Q1：Lua脚本会不会遇到死锁？
不会，Redis单线程执行脚本，没有锁的概念，但如果脚本里写了死循环（如while true do），会阻塞所有命令，务必控制脚本时间（默认5秒超时）。
Q2：如果Redis库存扣了，但后续订单创建失败怎么办？
常见解法：补偿机制，订单失败后，调用一个Lua回滚脚本（INCRBY恢复库存），更稳妥的是用消息队列异步创建订单，扣库存成功即发MQ消息。
Q3：热Key问题怎么解决？
单个商品库存Key被高频访问，可拆分库存：
// 分片：stock:phone:0, stock:phone:1, ... // 先在Lua里随机选一个分片尝试扣减，失败则试下一个。
Q4：为什么不直接用Redis的DECRBY+GET判断？
DECRBY返回负数时再INCRBY回补，会存在并发窗口：A扣成-1，B也扣成-2，两个都回补，导致库存虚增，Lua脚本完美规避。
Q5：Lua脚本需要预加载吗？
推荐使用SCRIPT LOAD获得SHA值，再用EVALSHA调用，减少网络传输脚本体，但首次调用或脚本变更需重新LOAD。
PHP+Lua脚本并非银弹，但它用最小的成本（一个Redis实例）解决了高并发扣库存的原子性和性能问题，关键在于理解：将“读-判断-写”压缩进一个Lua解释器里，借用Redis的单线程模型保证绝对串行，配合业务上的库存预热、失败补偿、分片策略，即可构建千亿级秒杀系统的核心骨架。
如果文章对你有启发,欢迎收藏转发，实践中遇到任何诡异问题，欢迎在评论区留言探讨。
