如何在Golang中开发一个基于Redis的分布式锁 Go语言Redis实战-Golang-PHP中文网

redis setnx只是分布式锁起点，必须配合ex过期、唯一value、lua原子解锁与续期才能满足互斥、防死锁、防误删等要求，单实例+正确实现已覆盖绝大多数场景。

如何在golang中开发一个基于redis的分布式锁 go语言redis实战

直接用 SETNX 加锁看似简单，但会立刻掉进超时失效、客户端崩溃不释放、误删他人锁的坑里。它只解决“没人占着时我能抢到”，不解决“我占着但挂了怎么办”和“我解的是自己的锁吗”。真正可用的分布式锁必须同时满足互斥、防死锁、可重入（可选）、防误删四个条件。

实操建议：

永远搭配 EX（过期时间）一起用：SET key value EX 30 NX，避免锁永久残留
value 必须是唯一标识（如 UUID 或进程+goroutine ID 组合），不能写死成 "1"，否则解锁时无法校验归属
解锁不能用 DEL key，必须用 Lua 脚本原子比对 value 再删除，否则 A 拿着过期锁还在执行，B 新建了同 key 锁，A 一删就把 B 的锁干掉了
不要依赖 Redis 主从同步来保证高可用——主挂了、从升主，旧锁可能在新主上丢失，这是 CAP 下的固有风险，得靠锁续期或业务容忍重入

Go 生态里 redigo 是最轻量又可控的 Redis 客户端，配合 Lua 脚本能绕过网络往返+判断的竞态。核心就两段：加锁用 SET ... NX EX，解锁用一段固定 Lua 脚本。

常见错误现象：用 GET + DEL 两步操作解锁 → 出现“检查是我，删的时候已不是我”的经典 race condition。

实操建议：

解锁脚本必须原子执行：

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

Go 中调用示例：redis.Eval(conn, luaScript, []string{lockKey}, lockValue)，返回 int64 类型结果，非 1 表示解锁失败
别把 Lua 脚本拼在代码里，用 embed.FS 或常量管理，方便审计和复用
注意 redigo 的连接复用机制，conn.Do() 后记得 conn.Close() 或归还到池，否则锁没发出去就卡住了

业务逻辑执行时间不确定，而 Redis 锁必须设过期时间防死锁，这两者天然矛盾。不续期 → 锁提前释放 → 其他节点闯入；乱续期 → 把别人刚抢到的锁续上了 → 数据错乱。

Golang Uber Dig

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

下载

使用场景：长耗时任务（如文件处理、批量导出、第三方 API 调用）必须配续期，且续期动作本身要绑定原锁持有者身份。

实操建议：

续期只能由加锁者发起，靠 value 校验，和解锁同理，也得用 Lua：if redis.call("GET", KEYS[1]) == ARGV[1] then return redis.call("EXPIRE", KEYS[1], ARGV[2]) else return 0 end
续期间隔建议设为锁 TTL 的 1/3（比如锁 30s，每 10s 续一次），避开网络抖动导致的误判
别用 goroutine 无脑定时续 —— 如果业务 panic 退出，续期 goroutine 可能还在跑，变成“幽灵续期”。应在 defer 或 context.Done() 里显式停掉
如果用 go-redsync 这类封装库，请确认它是否默认开启 auto-renew；很多库默认关着，得手动 mutex.LockWithContext(ctx, &redsync.Options{Expiry: 30 * time.Second, AutoRelease: true})

Redis 官方提过的 Redlock（多实例投票）在 Go 实际项目中极少落地。它解决的是单 Redis 实例故障下的锁可靠性，但代价是复杂度飙升、性能下降、且仍无法 100% 避免时钟漂移问题。

性能 / 兼容性影响：每次加锁要串行访问 3–5 个 Redis 实例，P99 延迟翻倍；各实例时间不同步时，可能出现“多数派认为锁有效，少数派认为已过期”的分裂状态。

实操建议：

绝大多数业务用单 Redis + 正确实现的 SETNX+Lua+renew 就够了。Redis 实例本身做哨兵或 Cluster，比 Redlock 更务实
真有强一致性要求（如金融核心账务），分布式锁不是第一选择 —— 改用数据库唯一约束、乐观锁、或专用协调服务（etcd + lease）更稳
如果团队坚持 Redlock，别手写，用 github.com/go-redsync/redsync/v4，但务必压测它的失败路径：某个 Redis 实例超时后，整个锁获取是否降级为单点行为？

真正难的从来不是怎么写一个加锁函数，而是怎么让锁的生命周期和业务执行周期严丝合缝地咬合在一起 —— value 唯一性、续期时机、panic 后清理、context 取消联动，漏掉任意一环，锁就从保险丝变成定时炸弹。