Golang实现Redis分布式锁教程

本文深入剖析了在 Go 语言中正确实现 Redis 分布式锁的关键实践与常见陷阱：强调必须使用原子命令 `SET key value EX seconds NX` 安全加锁，杜绝 `SETNX` 单独使用的危险；解锁和续期必须通过 Lua 脚本严格校验 clientID，避免误删或错续；澄清单节点 Redis 锁在严谨实现下已满足绝大多数业务可靠性需求，Redlock 并非必需且引入额外复杂性；最终指出锁的真正风险不在 Redis 本身，而在于 Go 代码中对 value 校验、原子性、TTL 管理和 key 设计等细节的疏忽——这些才是压测和线上故障反复暴露的核心痛点。

怎么用 SET 命令安全加锁，而不是只写 SETNX

直接调 SETNX 是踩坑起点，不是终点。它只管“键不存在时设值”，但不管锁过期、客户端崩溃、重试冲突这些现实问题。

• 必须搭配 EX（秒级过期）或 PX（毫秒级），否则 Redis 实例宕机后锁永久残留
• value 不能写死成 "1" 或 "locked"，得是全局唯一标识，推荐用 uuid.NewString() 生成
• 必须用原子命令一次完成：SET key value EX 30 NX —— NX 保证不覆盖他人锁，EX 防死锁，value 是解锁凭证
• 别信 redis.Client.SetNX() 封装，v9 版本里它底层就是 SET ... NX，但没自动带 EX，漏写就等于没加锁

为什么解锁必须用 Lua 脚本，而不能 GET + DEL 两步走

因为网络往返 + 判断 + 删除之间存在竞态窗口：A 检查到自己还持有锁，刚准备删，B 已经续期成功，A 一删就把 B 的锁干掉了——这就是经典「误删他人锁」错误。

• 解锁脚本只有一行核心逻辑：if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del", KEYS[1]) else return 0 end
• Go 中调用要用 redis.NewScript().Run()，传入 key 和当初生成的 clientID，返回 int64，非 1 即失败
• 别把脚本拼在代码里，用 const unlockScript = `...` 或 embed.FS 管理，方便审计和复用
• 如果用 redigo，记得 conn.Close() 或归还连接池，否则解锁请求发不出去，锁就卡死了

长任务怎么办？锁快过期了，怎么安全续期

业务执行时间不确定，而 Redis 锁必须设 TTL 防死锁，这天然矛盾。不续期 → 锁提前释放 → 并发闯入；乱续期 → 把别人刚抢到的锁续上了 → 数据错乱。

• 续期动作本身也要校验归属，同样得用 Lua：if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("expire", KEYS[1], ARGV[2]) else return 0 end
• 别用 EXPIRE key seconds 直接调，它不检查 value，谁都能续
• 建议起独立 goroutine 定期续期（比如每 1/3 TTL 调一次），但每次续前先 GET 校验本地 clientID 是否仍匹配——虽非原子，但比完全不校验强
• 更稳的做法是换 etcd：用 Lease + KeepAlive()，租约自动续，不用手写逻辑

Redlock 真有必要吗？单节点 Redis 锁到底靠不靠谱

绝大多数业务场景下，单节点 Redis + 正确实现的 SET + Lua 解锁 + 合理 TTL，已经足够可靠。Redlock 不是银弹，反而带来运维复杂度、时钟漂移风险和幽灵锁隐患。

• Redlock 要求至少 3 个独立主节点，且每个请求耗时必须远小于 TTL，实际中 GC STW、网络抖动都可能吃掉几毫秒，累积超限就失效
• 官方已弱化 Redlock 推荐，Martin Kleppmann 等专家也指出其在分区网络下无法保证安全性
• 如果你的 Redis 是云服务（如阿里云 Tair、腾讯云 CRS），背后已有高可用架构，再套 Redlock 反而增加失败路径
• 真正该警惕的不是单点，而是「锁内 panic 未 defer 解锁」「锁 key 设计没带业务维度（如 order:123）导致锁粒度太粗」

好了，本文到此结束，带大家了解了《Golang实现Redis分布式锁教程》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多Golang知识！