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

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

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

首先得明确一点：别指望单独调用SetNX就能搞定分布式锁。不带过期时间的锁，一旦客户端崩溃，就会变成一把永远打不开的“死锁”，后果不堪设想。真正的安全起点，是使用原子命令SET key value PX 30000 NX（毫秒级）或SET key value EX 30 NX（秒级）。这个命令的精髓在于，Redis服务端会一步到位，同时完成“检查不存在才设置”和“设置生存时间”这两个动作，中间没有任何可乘之机。

在Go语言中，使用go-redis/v9库时，client.Set(ctx, key, value, ttl)方法默认就启用了NX和PX语义，这很方便。但这里有个隐藏前提：你必须确认连接的Redis服务器版本在2.6.12以上。如果版本过旧，客户端库可能会将操作降级为两步执行，中间一旦发生故障，死锁的风险就又回来了。

• 锁的值（value）必须是全局唯一的：每个goroutine都应该独立生成一个随机字符串，比如使用uuid.NewString()。复用固定值或者简单的时间戳是绝对不行的，这会给锁的识别带来混乱。
• 过期时间（TTL）不是拍脑袋定的：一个实用的经验法则是，将其设置为业务关键路径P99耗时的2到3倍。例如，一个导出任务的P99耗时是1.8秒，那么锁的TTL可以设为4秒左右，为网络抖动和GC暂停留出足够缓冲。
• 锁的键（key）要有业务语义：建议采用类似lock:order:789这样的格式，加上业务上下文前缀。这不仅能清晰标识锁的用途，还能有效避免不同服务或模块之间因键名冲突而误删他人的锁。

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

解锁环节是另一个事故高发区。先GET检查再DEL删除，这个模式听起来合理，实则存在经典的竞态条件：客户端A查询到锁还存在，但在它执行删除指令前，锁可能因为过期而被客户端B获取并写入了新值。此时A的删除操作，就会错误地释放掉B刚持有的锁。

解决这个问题的唯一可靠方法，就是使用Lua脚本，在Redis服务端原子性地完成“检查-删除”操作：

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，就意味着释放失败——可能是锁已过期，也可能是值不匹配。这种情况下，必须记录日志或触发告警，绝不能静默忽略。

• 脚本需要妥善管理：不要把Lua脚本直接拼接在业务代码里。建议使用//go:embed指令或常量来管理，这样既方便进行灰度发布，也利于后续的审计和维护。
• 正确理解返回值：如果调用返回redis.Nil，这并不代表成功，而是意味着key不存在或传入的value与存储的值不匹配，本质上是一次失败的释放尝试。
• 谨慎使用defer：不要在defer中无条件调用释放锁的函数。释放前，应该先通过context.Done()或一个显式的标志位来判断，当前goroutine是否真的还持有这把锁。

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

认为设置了TTL就万事大吉？那就太天真了。垃圾回收（GC）的“Stop-The-World”暂停、网络瞬间抖动、甚至是意料之外的磁盘I/O延迟，都可能导致业务逻辑的执行时间超过锁的初始过期时间。如果不进行续期，锁就会提前失效，其他客户端便能趁虚而入，造成数据并发写入的风险。所以说，自动续期不是一个锦上添花的功能，而是一个关键的保命机制。

实现续期必须满足两个核心条件：第一，只能续自己持有的锁；第二，续期间隔要合理。

立即学习“go语言免费学习笔记（深入）”；

• 续期同样需要原子性：续期操作也必须封装在Lua脚本中，例如：if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("pexpire", KEYS[1], ARGV[2]) else return 0 end。绝不能先GET后EXPIRE。
• 续期间隔有讲究：一个常见的建议是，续期间隔设置为TTL的三分之一。例如，TTL为3秒，那么可以每隔1秒尝试续期一次。间隔太短会给Redis带来不必要的压力，间隔太长则可能在两次续期之间锁就过期了。
• 管理好续期协程的生命周期：启动一个独立的goroutine来执行续期后，务必在业务函数返回前，显式地调用对应的cancel()函数来停止它。否则，即使锁已经被正常释放，这个“幽灵”协程还会持续尝试为一个不存在的key续期，浪费资源且可能干扰逻辑。

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

需要特别清醒认识到的是，Redis本身并不提供任何关于锁获取的公平性保证。它没有内部队列，不记录等待者的顺序，也没有优先级概念。多个客户端同时争抢一把锁时，谁能在那个精确的毫秒命中SET ... NX，锁就归谁，这本质上是一种“抢购”模式。

因此，所谓的“公平性”，必须依靠客户端自身的逻辑来兜底。如果所有客户端在锁被占用时都立即、不间断地重试，就会形成“惊群效应”，把Redis服务器压垮。

• 重试必须带有退避和抖动：首次抢锁失败后，不要立刻发起下一次尝试。应该等待一个短暂的时间，并最好加上一个随机抖动，例如：time.Sleep(time.Millisecond * (50 + rand.Int63n(100)))。这能有效打散多个客户端的重试节奏。
• 考虑指数退避：对于连续多次抢锁失败的情况，可以采用指数退避策略来增加重试间隔，但退避的上限不应超过业务逻辑本身的超时时间，否则就失去了重试的意义。
• 集群环境下的优化：如果业务部署在Redis Cluster模式下，并且允许的话，可以将锁的key设计为带有hash tag的格式，例如{lock:order}:789。这能确保key被路由到同一个slot上，避免因跨slot访问带来的MOVED重定向开销。
• 强公平性需求请换方案：如果业务场景对公平性有严格要求，比如金融交易中的订单处理，那么就不应该强求用Redis来实现。像etcd这类基于Raft协议的一致性系统，其提供的clientv3.Txn().If(...).Then(...).Else(...)事务操作配合租约（Lease），能提供线性一致的、近似先到先得的排队效果，这才是更合适的选择。

最后，分享一个在真实场景中极易被忽略，但一旦忽略就必出问题的细节：锁释放后的状态清理。这不仅仅是指释放Redis中的那个key，还包括：确保续期的goroutine被正确取消、将业务context的生命周期与锁的生命周期解绑、以及设计好释放失败时的降级方案（例如，是降级为本地限流，还是直接向上层返回错误）。这些细节往往不会写在主流程的核心代码里，如果仅依赖注释或文档，上线后几乎肯定会引发难以排查的故障。