Go语言Redis分布式锁实现教程

本文深入剖析了Go语言中Redis分布式锁的正确实现方式，直击SETNX命令因缺乏原子性导致死锁的核心缺陷，强调必须使用SET key value EX seconds NX原子命令配合唯一value与Lua脚本校验删除，规避误删、死锁、超时误判等高频陷阱；同时厘清了Redlock在多数生产场景中的过度设计本质，指出单实例+健壮的加锁/解锁/续期机制（含context超时控制、动态续期goroutine生命周期管理）已足够可靠，并提醒开发者：分布式锁真正的难点不在代码实现，而在于业务语义对齐——如锁粒度、超时设定、异常回滚与资源清理的协同设计。

Redis SETNX 命令为什么不能直接当分布式锁用

因为 SETNX 只能设值，没法同时设置过期时间，导致锁可能永远不释放。比如进程写完 SETNX key 1 就崩溃了，后续谁也拿不到锁。

正确做法是用 Redis 的原子命令 SET key value EX seconds NX，它把“判断不存在 + 设值 + 过期”三步压成一步。Go 客户端（如 github.com/go-redis/redis/v9）对应的是 SetNX 方法，但必须显式传 WithContext 和 redis.SetArgs{Expire: time.Second * 30}，否则还是没过期逻辑。

• 别用 SETNX + EXPIRE 两步：中间崩溃就死锁
• 过期时间不能拍脑袋定：要大于业务最大执行时间，再加一点缓冲（比如 1.5 倍），否则锁自动释放后别的协程进来，原协程还在删锁，就误删了
• 客户端连接中断时，context.WithTimeout 必须包住整个 SetNX 调用，不然网络卡住会 hang 住 goroutine

Go 里怎么安全地释放 Redis 分布式锁

释放锁不是简单 DEL key，得确保只删自己设的锁——否则 A 拿到锁，B 超时后自己又抢到，A 结束时一删，就把 B 的锁干掉了。

通用解法是：设锁时用唯一值（比如 UUID 或随机字符串）作为 value；删锁时用 Lua 脚本比对 value 再删。Go 客户端调用 Eval 执行这段脚本：

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

注意：Eval 的 keys 参数必须是 []string{"my_lock_key"}，args 是 []interface{}{lockValue}，顺序错或类型错都会返回 0 且不报错。

• value 不能用时间戳或 PID：可能重复；推荐用 uuid.NewString()
• 别在 defer 里无条件删锁：万一加锁失败，defer 还是会跑，删一个根本不存在的 key 倒没事，但掩盖了加锁失败的问题
• Lua 脚本必须用 Eval，不能拆成 GET + DEL：中间可能被别的 client 插入

Redlock 算法在 Go 项目里要不要上

大多数业务不需要 Redlock。它解决的是“单 Redis 实例故障导致锁失效”的问题，但代价是性能下降、实现复杂、且实际场景中多数锁冲突发生在同一实例内。

如果你用的是云 Redis（如阿里云、AWS Elasticache），背后已经是主从+哨兵/集群模式，单点故障概率极低；真要高可用，优先做 Redis 连接池健康检查 + 自动重连，而不是堆 Redlock。

• Redlock 要求向 ≥3 个独立 Redis 实例发请求，耗时翻倍，对延迟敏感的服务不友好
• go-redsync 这类库默认用系统时间算锁剩余时间，但各机器时钟不同步会导致误判；得配 NTP 且容忍误差 ≤100ms
• 除非你有跨机房部署、强一致要求、且已确认单实例方案扛不住，否则先用单实例 + 正确的 SET + Lua 删除

锁续期（renew）什么时候必须做

当业务执行时间不可控（比如要调外部 HTTP 接口、处理大文件、等用户回调），且超时时间没法预估时，才需要自动续期。

Go 里常见做法是启动一个后台 goroutine，在锁过期前 1/3 时间调用 GetExpiry 拿剩余 TTL，再用 Lua 脚本更新过期时间。但注意：这个 Lua 脚本也得校验 value，否则又是误续别人锁。

• 续期不是“每秒刷一次”，而是按锁初始 TTL 动态算下次续期时间，避免高频打 Redis
• goroutine 必须绑定到锁生命周期：加锁成功后才启，释放锁或 context cancel 时 stop，否则 goroutine 泄漏
• 别依赖 PTTL 命令：有些 Redis 代理（如 Twemproxy）不支持，得用 GET + 业务层记录时间戳的方式兜底

真正难的从来不是“怎么写锁”，而是“哪里该加锁、加多长、谁负责清理”。比如扣库存用 Redis 锁，但订单创建失败后，锁释放了库存却没回滚，这已经不是锁的问题了。

本篇关于《Go语言Redis分布式锁实现教程》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于Golang的相关知识，请关注golang学习网公众号！