如何在Golang框架内集成Redis分布式锁

不行。多实例下sync.Mutex失效；rdb.SetNX若非原子SET key value NX EX，崩溃会导致死锁；加锁必须用client.Set确保原子性，value须唯一（如uuid），解锁必须用Lua脚本校验value再del，续期也需Lua校验，且TTL应设为业务P99×2并配看门狗。

直接在 Gin/Echo 等框架里调 rdb.SetNX 或写个全局 sync.Mutex 就算集成分布式锁？不行。多实例部署下，sync.Mutex 完全失效；而 rdb.SetNX 若底层没走原子 SET key value NX EX，中间一崩溃，锁就永远卡住。

加锁必须用 client.Set 而不是 SetNX

Go-redis/v9 的 client.Set 默认走原子 SET key value NX EX，安全；但 client.SetNX 在旧 Redis 实例（如 2.4）或禁 Lua 的环境会 fallback 成 SETNX + EXPIRE 两步——中间若进程 panic、网络中断，key 就永不超时。

• 显式传 redis.WithValue 和 redis.WithExpiration，确保命令结构可控
• value 必须是每个请求独立生成的，比如 uuid.NewString()，不能复用字符串或写死为 "1"
• EX 用秒级足够，除非你要毫秒精度（那就用 PX）；注意别把 time.Second 误乘成纳秒传给 EX，否则锁 1 秒变 10⁹ 秒
• TTL 建议设为业务 P99 耗时 × 2，比如导出接口最长 1.2s，就设 2 * time.Second；太短易掉锁，太长拖慢故障恢复

解锁必须走 redis.NewScript + Lua 脚本

用 rdb.Del(ctx, key) 或先 GET 再 DEL 是高危操作：A 拿着锁还没删完，B 已抢到新锁，A 一删就把 B 的锁干掉了——这不是偶发 bug，是必然竞态。

• 解锁脚本固定用：if redis.call("GET", KEYS[1]) == ARGV[1] then return redis.call("DEL", KEYS[1]) else return 0 end
• Go 中定义：unlockScript := redis.NewScript(unlockLua)，调用时传 []string{key} 和 value，顺序不能错
• 返回值必须判断是否为 int64(1)，0 或 error 都代表失败，此时应立即中止业务逻辑，而不是重试——锁已不属于你
• 脚本别拼在函数里，用 embed.FS 或 const 管理，方便审计和灰度替换

长任务必须配看门狗续期，且续期也得用 Lua

锁不能不设 TTL（主从切换后锁丢失），又不能设太长（影响故障恢复），唯一解法是续期——但 A 续了 B 的锁，B 还以为自己持锁在改数据，就完了。

立即学习“go语言免费学习笔记（深入）”；

• 续期脚本同样要校验：if redis.call("GET", KEYS[1]) == ARGV[1] then return redis.call("EXPIRE", KEYS[1], ARGV[2]) else return 0 end
• 续期间隔建议为 TTL / 3，比如 TTL=2s，就每 600ms 续一次；太密压 Redis，太疏易掉锁
• 续期 goroutine 必须绑定到请求 context，并在业务函数 return 前显式 cancel()；否则锁释放了，后台还在不停续——变成“幽灵续期”
• 别用 client.Expire 单独调，那是裸奔；它不校验 value，等于把锁拱手让人

框架集成时锁必须绑定单次请求的 context.Context

常见错误是把锁变量声明成全局或结构体字段，导致并发请求互相覆盖 value 或 leaseID；或者锁生命周期脱离 HTTP 请求上下文，造成 goroutine 泄漏或锁滞留。

• 每次请求都应生成新 value、新 ctx（带 timeout）、新续期 goroutine
• 在 Gin 中，推荐通过 c.Request.Context() 派生子 context，设好 deadline 后传入锁操作
• 别让锁对象逃逸到 handler 外部作用域；尤其避免在 middleware 里缓存锁实例再复用
• context 超时时间必须明显短于 TTL，否则网络抖动时容易提前 cancel 导致续期失败、锁被清掉

最易被忽略的点：Redis 主从异步复制可能引发脑裂——两个节点同时认为自己持锁。这不是客户端能绕过的，得靠业务容忍重入、或换 etcd（Raft 强一致，但延迟高、API 重）。单 Redis 实例 + 正确实现的 SET+Lua 已覆盖绝大多数场景，Redlock 不是银弹，运维成本远超收益。