当前位置：首页 > 文章列表 > 文章 > php教程 > Redis分布式锁实现：Redlock算法与高并发方案

Redis分布式锁实现：Redlock算法与高并发方案

2026-05-28 12:56:39 0浏览收藏

本文直击PHP项目中分布式锁的常见误区，明确指出95%的场景完全无需复杂低效的Redlock算法，真正关键的是正确使用Redis原生命令SET key value NX EX seconds实现原子加锁，并严格保证value唯一性、超时时间合理、释放锁必须通过Lua脚本原子执行；同时警示高并发下锁失效往往源于业务逻辑缺陷——如锁粒度粗、调用外部服务阻塞、异常未兜底等，而非Redis本身，强调“用对基础命令+守好业务边界”远比盲目追求高级算法更可靠、更高效。

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

PHP 用 `SET` 命令加锁就够了，别急着上 Redlock

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

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

超时时间（EX）必须大于业务最大执行耗时，但不宜过长（比如设成 300 秒），否则故障时锁残留太久
value 必须是全局唯一标识（如 uniqid('', true)），不能写死字符串，否则释放锁时无法校验所有权
不要用 SETNX + EXPIRE 分两步，网络中断或进程崩溃会导致锁有值无过期时间

释放锁必须用 Lua 脚本，`GET` + `DEL` 是错的

常见错误是先 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。

脚本里用 KEYS[1] 和 ARGV[1]，别写成硬编码字符串
返回值为 1 表示删除成功，0 表示非持有者调用，业务层要据此判断是否继续重试
别在脚本里加日志或 sleep，Redis 执行 Lua 是阻塞主线程的

Redlock 在 PHP 里跑不稳，Predis 的实现容易踩三个坑

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

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

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