基于 Redis 的 PHP 分布式锁实现：Redlock 算法原理与高并发场景下的互斥方案-php教程-PHP中文网

PHP项目通常只需用SET key value NX EX seconds原子加锁，无需Redlock；必须确保NX防覆盖、EX防死锁、value唯一、Lua脚本安全释放锁。

基于 redis 的 php 分布式锁实现：redlock 算法原理与高并发场景下的互斥方案

95% 的 PHP 项目根本不需要 Redlock。它设计初衷是为多 Redis 主节点做强一致性共识，但 PHP 应用通常只连一个 Redis 实例（哪怕背后是哨兵或 Cluster），硬套 Redlock 只会拖慢请求、增加出错路径，且官方 redis 扩展不支持跨实例原子协调。

真正该盯住的是：SET key value NX EX seconds 这条命令是否被正确使用。它同时满足「键不存在才设值」+「自动过期」两个条件，是原子性加锁的底线。漏掉 NX 会覆盖别人持有的锁，漏掉 EX 会导致死锁——这两点比算法名字重要得多。

常见错误是先 GET 判断值匹配，再 DEL 删除。这中间存在竞态窗口：A 进程刚读完值，B 进程就释放了锁并退出，A 接着删掉 B 新设的锁——直接破坏互斥性。

正确做法是把「判断值相等」和「删除」封装进一段 Lua 脚本，由 Redis 单线程原子执行：

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

调用时传入 $redis->eval($script, 1, $lockKey, $identifier)。注意参数顺序：第一个是脚本，第二个是 key 数量（固定为 1），后面才是 key 和 value。

如果你确实评估后需要 Redlock（比如跨机房部署、对锁丢失容忍度极低），用 Predis 实现时要注意：

redis-tools

按类别查找Redis命令、检测服务器连接、监控键数量和内存占用，支持离线速查表。

下载

五个 Redis 节点必须是相互独立的主节点（不能是同一集群的不同分片），否则单点故障仍可能导致多数派失效
获取锁时每个节点的 SET 命令必须带 NX + PX（毫秒级），且总耗时不能超过锁 TTL 的一半，否则算作失败
Predis 默认不启用连接超时，得手动给每个 client 加 ['read_write_timeout' => 0.1]，不然某个节点卡住会拖垮整个锁流程

更现实的选择是：用 Redis 哨兵模式保障单实例高可用，配合合理的锁超时与重试逻辑，比强行拼 Redlock 更可靠。