Golang 实现基于 Redis 的分布式锁“看门狗”自动续期机制

在分布式锁这个老生常谈的话题里，有个坑几乎每个人都会踩：直接拿 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 校验、脚本原子性、上下文传播，哪一环漏了，分布式锁就从保护伞变成了定时雷。