Golang 实现高性能的分布式锁多节点竞争公平性实战-Golang-PHP中文网

Redis分布式锁必须使用SET key value NX PX milliseconds原子命令实现，NX保证互斥性，PX防止死锁，value须为唯一随机值，解锁和续期均需Lua脚本保障原子性。

golang 实现高性能的分布式锁多节点竞争公平性实战

Redis SET PX NX 是加锁的唯一安全起点

别信 SetNX 单独调用能搞定分布式锁——它不带过期时间，一旦客户端崩溃，锁就永远卡住。必须用原子命令 SET key value PX 30000 NX（毫秒级）或 SET key value EX 30 NX（秒级），让 Redis 服务端一步完成“不存在才设值 + 同时设 TTL”。go-redis/v9 的 client.Set(ctx, key, value, ttl) 默认启用 NX 和 PX，但得确认你连的是 Redis 2.6.12+；老版本 fallback 成两步操作，中间挂掉就留死锁。

value 必须是每个 goroutine 独立生成的随机字符串，比如 uuid.NewString()，不能复用固定值或时间戳
ttl 不是随便拍的：设为业务 P99 耗时 × 2～3，例如导出任务 P99 是 1.8s，那就设 4 * time.Second
key 建议带业务上下文前缀，如 lock:order:789，避免跨服务误删

Lua 脚本释放锁是防误删的硬门槛

用 GET 判断再 DEL 是经典竞态：A 查到锁存在，正要删，B 已抢到并写入新值，A 一删就把 B 的锁干掉了。唯一可靠方式是 Lua 脚本原子执行：

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

Go 中调用：unlockScript.Run(ctx, rdb, []string{key}, lockValue)，返回非 1 就代表释放失败，必须记录日志或告警，不能静默忽略。

脚本别拼在代码里，用 //go:embed 或 const 管理，方便灰度和审计
如果返回 redis.Nil，说明 key 不存在或值不匹配——不是成功，是失败
别在 defer 里无条件调用释放，得先判断自己是否真持有锁（比如通过 context.Done() 或显式标志）

自动续期不是可选功能，而是保命机制

GC 暂停、网络抖动、磁盘 I/O 延迟都可能让业务执行超过 TTL。不续期 = 锁提前丢失 = 并发写入风险。续期必须满足两个条件：只续自己的锁、间隔合理。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

续期脚本也得用 Lua：if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("pexpire", KEYS[1], ARGV[2]) else return 0 end
续期间隔建议为 TTL / 3，比如 TTL=3s，就每 1s 续一次；太密压 Redis，太疏容易掉锁
启动续期 goroutine 后，业务函数 return 前必须显式 cancel() 对应 context，否则变成“幽灵续期”——锁早释放了，后台还在给一个不存在的 key 续期

多节点公平性靠客户端逻辑兜底，Redis 本身不保证

Redis 没有队列、没有优先级、不记录等待者顺序。所谓“公平”，只能靠客户端实现重试退避 + 随机 jitter。直接轮询 SET ... NX 会引发 thundering herd，把 Redis 打满。

首次抢锁失败后，不要立即重试，用 time.Sleep(time.Millisecond * (50 + rand.Int63n(100))) 加随机抖动
连续失败 3 次后，考虑指数退避，但上限别超业务超时时间
如果业务允许，把锁 key 设计成带 hash tag 的格式，如 {lock:order}:789，确保 Redis Cluster 下 key 落在同一 slot，避免 MOVED 重定向开销
真正需要强公平语义（比如金融类调度），别硬刚 Redis——换 etcd，用 clientv3.Txn().If(...).Then(...).Else(...) 配合租约，它的 Raft 日志天然支持线性一致的排队效果

真实场景中，最易被忽略的是「锁释放后的状态清理」：续期 goroutine 的 cancel、context 的生命周期绑定、以及释放失败时的 fallback 处理（比如降级为本地限流或直接报错）。这些细节不写进主流程，只靠注释或文档，上线后必出问题。