PHP使用Redis实现分布式锁详解

本文深入剖析了PHP中使用Redis实现分布式锁的常见陷阱与可靠实践，指出单纯依赖SETNX易导致死锁，并强调原子性设置键、过期时间及唯一标识值的必要性；详细讲解了如何用Redis的SET命令（NX+EX）安全加锁，以及必须通过Lua脚本校验value后再删除的严谨解锁机制；同时澄清了本地文件锁在分布式环境下的无效性，警示主从切换引发的锁重复获取风险，并务实建议：与其过度追求理论完美的分布式锁，不如结合数据库唯一约束、幂等设计和业务兜底策略，以更稳健的方式应对高并发场景下的数据一致性挑战。

Redis SETNX 命令加锁为什么经常失效

因为 SETNX 只管“设值”，不管“过期”，一旦客户端崩溃或网络中断，锁就永远卡在 Redis 里，其他服务等死。这不是锁，是幽灵锁。

真正可用的方案必须同时满足：原子性设置 key + 过期时间 + 唯一标识（防止误删）。PHP 里最稳的做法是用 SET 命令的 EX 和 NX 选项，再带上 GET 不行，得用随机 value 标识持有者：

• $lockKey = 'order:pay:12345';
• $lockValue = uniqid('', true); // 必须全局唯一，不能用时间戳或固定字符串
• $result = $redis->set($lockKey, $lockValue, ['nx', 'ex' => 30]); // 30秒自动过期

注意：nx 和 ex 要一起传，老版本 PHP Redis 扩展不支持数组参数，得拼成 ['NX', 'EX', 30]；PHP 8.0+ 的 Redis::set() 才认关联数组。

解锁时 DEL 直接删 key 会出大问题

DEL 是无脑删，如果 A 拿到锁但执行慢，超时自动释放了，B 拿到了新锁，这时 A 才去调 DEL，就把 B 的锁干掉了——典型的“越权解锁”。

解锁必须校验 value 是否匹配，且整个操作要原子。PHP 没有原生支持 Lua 脚本的便捷封装，所以得手写 EVAL：

if redis.call("GET", KEYS[1]) == ARGV[1] then
    return redis.call("DEL", KEYS[1])
else
    return 0
end

对应 PHP 调用：

• $script = "if redis.call('GET', KEYS[1]) == ARGV[1] then return redis.call('DEL', KEYS[1]) else return 0 end";
• $redis->eval($script, [$lockKey], 1, $lockValue); // 第三个参数是 key 数量，别写错

漏掉 $lockValue 或把 1 写成 0，脚本就永远返回 0，锁删不掉。

PHP-FPM 多进程下用 file_get_contents + flock 不算分布式锁

有人用 flock() 锁本地文件，或者用 file_get_contents 读写一个 lock.txt，这只能拦住同一台机器上的多个 PHP 进程，跨服务器完全无效。Redis、etcd、ZooKeeper 才是真分布式场景的基础设施。

如果你的业务部署在多台机器，又没上 Redis，别硬凑——要么加 Redis，要么承认当前架构不支持强一致性锁，改用幂等设计或最终一致性补偿。

另外，pcntl_fork() 在 Web SAPI（如 FPM）里基本不可用，信号处理混乱，别试。

Redis 主从切换时锁可能重复获取

主节点写入锁成功，还没同步到从节点，主挂了，从升主，新主上没有这个 key，另一个客户端立刻 SET 成功——两个服务同时持锁。这是 Redis 单机模式天然缺陷。

严格场景必须用 Redlock 算法（5 个独立 Redis 实例，多数派写入才算成功），但 PHP 生态里靠谱实现极少，php-redlock 库已多年未维护，且 Redlock 本身在某些网络分区下仍有争议。

更现实的选择是：接受小概率冲突，用业务层兜底（比如支付订单加数据库唯一索引 + 插入前 SELECT 判断），而不是在锁上死磕。

锁不是银弹，它只是把并发问题从“执行中”挪到“获取时”。真正难的永远是业务逻辑怎么扛住重试和乱序。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。