Redis分布式锁可有效防止秒杀超卖：先用SETNX加锁并设过期时间，再校验库存、扣减、安全解锁；推荐Lua脚本原子执行或RedLock多节点容错，辅以DB行锁和库存分段限流增强可靠性。
如果您正在搭建PHP网站的秒杀活动功能，但面临高并发下商品超卖问题，则可能是由于库存扣减未加分布式互斥控制。以下是实现防超卖逻辑的具体步骤：
一、使用Redis SETNX命令实现基础分布式锁
该方法利用Redis单线程原子性特性，通过SETNX（SET if Not eXists）指令尝试设置唯一锁键，仅当锁不存在时写入成功，从而保证同一时间只有一个请求能进入库存校验与扣减流程。
1、在PHP中通过Redis扩展调用setNx方法，传入锁键名（如“seckill:lock:goods_123”）和随机唯一值（如uniqid()生成的字符串）。
2、判断返回值是否为1，若为1表示获取锁成功，继续执行库存查询与扣减；若为0则表示锁已被占用，直接返回“抢购繁忙”提示。
立即学习“PHP免费学习笔记（深入）
”；
3、库存校验通过后执行DECR命令扣减Redis中对应商品的库存计数器（如“seckill:stock:123”）。
4、使用DEL命令删除锁键前，先通过GET获取当前锁值，比对是否与自身持有的随机值一致，一致才执行删除，避免误删其他请求的锁。
二、采用Redis Lua脚本封装原子化锁操作
该方法将加锁、校验、扣减、释放锁等多步操作封装进一段Lua脚本，在Redis服务端一次性执行，彻底规避网络往返导致的竞态条件，确保整个秒杀核心逻辑不可分割。
1、编写Lua脚本，接收商品ID、锁过期时间、库存阈值作为参数，先尝试SETNX并设置EXPIRE，再读取库存值，若大于0则执行DECR并返回结果，否则返回失败标识。
2、在PHP中使用
redis->eval()方法执行该脚本，传入脚本内容、参数个数、商品ID、锁过期毫秒数、最小库存值。
3、解析eval返回值：返回1表示成功扣减，返回0表示库存不足，返回-1表示加锁失败或锁已存在。
4、根据返回值决定是否生成订单记录，并向客户端响应对应状态码与消息。
三、基于Redis RedLock算法构建多节点容错锁
该方法针对单Redis实例故障风险，同时向多个独立Redis节点发起加锁请求，在大多数节点（N/2+1）成功时判定锁获取成功，提升分布式环境下的可用性与一致性保障能力。
1、初始化三个以上物理隔离的Redis连接实例（如redis1、redis2、redis3），确保它们不共享主从关系。
PHP 8.5.5 PHP 8.5.5 是 PHP 8.5 分支的维护更新版本。该版本延续了“小步快跑”的迭代逻辑，通过深度错误修复、底层性能微调以及安全加固，旨在为开发者提供一个更健壮、更高效的运行环境。该版本严格遵守语义化版本规范，不包含破坏性变更。
下载2、为每个实例生成相同锁键与唯一随机值，并设置统一过期时间（如5000毫秒），调用setNx + expire组合命令。
3、统计成功加锁的节点数量，若达到法定数量（如3节点中至少2个返回true），则记录整体锁获取起始时间。
4、计算实际剩余有效锁时间（初始过期时间减去加锁耗时），在业务处理完成后，向所有成功加锁的节点发送解锁请求，使用前述值比对方式安全删除。
四、结合数据库行级锁进行最终库存落库校验
该方法在Redis预减库存基础上，于订单写入数据库阶段再次使用SELECT ... FOR UPDATE语句锁定商品库存行，防止Redis与DB间因网络延迟或进程崩溃导致的状态不一致。
1、在事务开启后，执行SELECT stock FROM goods WHERE id = 123 FOR UPDATE语句，强制获取该商品记录的排他锁。
2、检查查出的stock字段值是否仍大于0，若否，说明已被其他事务抢先扣减，抛出异常并回滚事务。
3、若库存充足，则执行UPDATE goods SET stock = stock - 1 WHERE id = 123。
4、插入订单记录，提交事务。此时
Redis中的预减操作与数据库最终扣减必须严格一一对应，不可跳过任一环节。
五、引入库存分段预热与令牌桶限流协同控制
该方法将总库存按固定粒度（如每100件为一段）拆分为多个Redis计数器，在活动开始前预加载到内存，并配合Nginx或PHP-Swoole层的令牌桶算法限制单位时间请求数，从入口处削减无效流量压力。
1、在秒杀开始前，将商品ID为123的10000件库存拆为100个key（如“seckill:stock:123:001”至“seckill:stock:123:100”），每个key初始值设为100。
2、用户请求到达时，先由Swoole Worker进程通过原子INCR命令从某一段中领取一个令牌，若返回值≤100则视为领取成功，否则尝试下一段，直至全部段位耗尽。
3、领取成功后，将该段编号与用户ID写入临时队列（如Redis List），交由后台消费者进程异步完成订单创建与数据库更新。
4、所有段位的INCR结果总和即为实时已分配库存量，
该总数必须始终小于等于原始库存上限且不可逆向增加。