Golang 实现基于 Redis 的分布式锁“看门狗”自动续期机制
采用看门狗协程解决分布式锁因业务超时提前释放问题:锁到期前通过Lua脚本原子验证客户端标识并续期。协程生命周期与业务绑定,由context控制启停,防止泄漏,确保锁安全自动续期。
在分布式锁这个老生常谈的话题里,有个坑几乎每个人都会踩:直接拿 SETNX 加个过期时间就当锁用了,结果业务一超时,锁提前释放,并发冲突瞬间爆雷。问题出在哪?说白了,业务逻辑的执行时长根本不可控,你预估的“足够长”的过期时间,要么太长拖慢故障恢复,要么太短直接翻车。
那怎么办呢?核心思路其实就一句话:加锁之后,让客户端自己来续期。具体做法是启动一个后台协程,在锁快要到期前,不断用 GETSET 或 PEXPIRE 把 TTL 往后延——这个协程就是“看门狗”。但这里有个硬性前提:只有持有锁的客户端才有资格续期,绝不能让别人越权操作。
所以,续期前必须验证锁的 value 是不是当前客户端的唯一标识(比如 UUID),否则就会出现 A 的锁被 B 续了的乱子。而且续期这个操作本身必须是原子的,用 Lua 脚本做“检查 value + 更新 TTL”是最稳妥的做法,能彻底避免 GET、判断、SET 三步之间的竞态问题。另外,看门狗协程的生命周期必须跟业务逻辑绑定,业务结束或主动解锁时要立马停掉它,不然残留的 goroutine 会一直在后台刷 Redis。
用 Lua 脚本安全续期:eval 是关键
Redis 执行 Lua 脚本是原子的,正好适合“检查 value 是否匹配 + 更新 TTL”这一对操作。在 Go 里调用 Eval 方法传入脚本和参数即可。
典型的续期脚本逻辑是这样的:
if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("pexpire", KEYS[1], ARGV[2])else return 0end
对应的 Go 调用:
script := redis.NewScript(`if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("pexpire", KEYS[1], ARGV[2])else return 0end`)result, err := script.Run(ctx, rdb, []string{lockKey}, clientID, renewalTTL).Result()
clientID必须是加锁时 set 的 value,建议用uuid.NewString()生成,全局唯一且无状态。renewalTTL推荐设为锁初始 TTL 的 1/3~1/2(比如初始 30s,续期设 10s),这样能留出网络和执行余量。- 脚本返回
1表示续期成功,返回0说明锁已经不属于当前客户端,此时应该立刻停掉看门狗。
看门狗协程怎么启、怎么停才不泄漏
不能图省事直接用 go func() { ... }() 启动后就撒手不管。必须能响应业务完成、上下文取消、锁被主动释放这些信号。
- 用
context.WithCancel(parentCtx)派生一个子 ctx,业务函数退出时调用cancel(),看门狗内部用select监听ctx.Done()。 - 主动解锁时(比如 defer 解锁),除了删 key,还要显式 cancel 看门狗的 ctx——否则它还在后台刷 Redis。
- 看门狗内部每次续期前先
select { case <-ctx.Done(): return; default: },避免 cancel 后还执行一次续期。 - 别用
time.Ticker无脑 tick,改用time.AfterFunc或带 jitter 的重试,防止多个实例续期时间完全同步,导致 Redis 出现流量尖峰。
实际加锁流程中哪些地方最容易漏掉续期逻辑
写完看门狗代码不代表万事大吉。常见的问题点在于:加锁成功但没来得及启动协程、panic 导致 defer 没执行、context 被意外覆盖、错误处理分支忘记停掉看门狗。
- 加锁函数返回后,必须立刻检查是否成功,只在
ok == true时才启动看门狗——失败时启动就是空转。 - 业务逻辑外层包一层
defer,里面做两件事:调用unlock()和cancelWatchdog(),缺一不可。 - 如果业务函数本身接收 context,别直接用传入的 ctx 启动看门狗;应该用
context.WithTimeout(ctx, lockTTL)派生一个子 context,否则上游 timeout 不会触发看门狗退出。 - 测试时故意让业务 sleep 超过初始 TTL,观察 Redis 中 key 的 TTL 是否动态延长,以及日志里有没有 “lock lost during renewal” 这类提示。
续期不是简单地加一个 goroutine 就完事,它是锁生命周期里的隐式状态机——启停时机、value 校验、脚本原子性、上下文传播,哪一环漏了,分布式锁就从保护伞变成了定时雷。


































