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

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

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 更可靠。

高并发下锁失效的真凶往往是业务逻辑本身

很多人盯着 Redis 命令是否原子，却忽略业务层的问题。比如秒杀场景中，扣库存前没查剩余量，导致锁内操作失败后直接释放锁，而下游服务还在继续处理——锁没失效，是业务没兜住。

关键检查点：

• 锁的粒度是否合理？用 user_id 锁不如用 order_id 锁精准，避免不同订单互相阻塞
• 锁持有期间是否调用了外部 HTTP 请求？超时或重试可能让锁提前过期
• 有没有在 try/catch 外部释放锁？异常抛出后锁没释放，等于人为制造死锁

最常被忽略的一点：锁的 value 标识符必须在加锁和释放时完全一致。PHP 中注意 uniqid() 默认不带 microseconds 参数，高并发下可能重复；建议用 bin2hex(random_bytes(16)) 生成真正随机字符串。

本篇关于《Redis分布式锁实现：Redlock算法与高并发方案》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！