如何在 Go 中实现分布式锁的续期和防死锁机制-Golang-PHP中文网

单靠redis setnx超时不够用，因业务超时会导致锁被误回收；须用唯一token+lua原子续期，并设租约与心跳机制防死锁。

如何在 go 中实现分布式锁的续期和防死锁机制

为什么 `redis.SetNX` 单靠超时不够用

Redis 的 SET key value EX seconds NX 确实能加锁，但业务执行时间不确定——若处理耗时超过 EX 设置的过期时间，锁自动释放，其他节点可能趁机抢占，导致并发冲突。这不是“锁失效”，而是“锁被误回收”。续期本质是动态延长这个 EX，但必须确保只有持锁者能续，否则就变成谁都能刷过期时间。

用 `redis.Eval` 原子续期：检查 + 延长必须一步到位

不能先 GET 再判断再 EXPIRE：中间存在竞态窗口。正确做法是 Lua 脚本在 Redis 端原子执行：

if redis.call("GET", KEYS[1]) == ARGV[1] then
    return redis.call("EXPIRE", KEYS[1], ARGV[2])
else
    return 0
end

调用时传入锁 key、当前持有者的唯一 token（如 UUID）、新过期秒数。返回 1 表示续期成功，0 表示 token 不匹配（已被别人覆盖或已释放）。

Alibabacloud Sdk Client Initialization For Golang

初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。

下载

token 必须在加锁时生成并写入 value，且全局唯一（推荐 uuid.NewString()）
续期间隔建议设为锁过期时间的 1/3～1/2（例如锁设 30s，每 10s 续一次），留出网络和执行余量
不要无限制续期——业务逻辑卡死时，应有兜底超时（比如最大续期次数 × 续期间隔）

防死锁的关键不是“加锁前检查”，而是“锁自带租约+健康心跳”

有人想加锁前先查 key 是否存在，再决定是否重试——这毫无意义，因为查完瞬间别人就可能已加锁。真正防死锁靠两点：

所有锁必须设初始过期时间（EX），绝不依赖手动释放；即使客户端崩溃，锁也会自动清理
续期操作本身要有失败熔断：连续 3 次续期返回 0，说明 token 失效，应主动放弃并报错，而不是继续等或重试加锁
业务代码中，defer unlock() 不可靠（panic 可能跳过），推荐用带上下文取消的锁结构体封装，配合 runtime.SetFinalizer 做最后保险（仅辅助，不替代超时）

Go 客户端选型和常见坑

用 github.com/go-redis/redis/v9 时注意：

client.SetNX(ctx, key, value, ttl) 的 value 必须是你自己生成的 token，别用固定字符串
续期脚本要用 client.Eval(ctx, script, []string{key}, token, newTTL.Seconds())，注意 Seconds() 是 float64，Lua 的 EXPIRE 接收整数秒，所以建议传 int(newTTL.Seconds())
别把锁 key 设成纯业务 ID（如 "order:123"），加上服务名前缀更好排查："svc-order:lock:123"
RediSearch 或 Redis Cluster 环境下，确保锁 key 的 slot 一致（用 {...} 包裹 key，如 "{order:123}:lock"）