基于Golang的云原生分布式锁：解决K8s多实例并发冲突

用 redis.client.set 实现分布式锁必须使用 set key value ex 30 nx 原子命令，go 中需传 redis.setnx 模式与过期时间；value 必须唯一（如 uuid），释放锁须用 lua 脚本校验 value 后删除；续期间隔应远小于 ttl 并设超时；etcd 方案需确保 leaseid 与 keepalive 生命周期严格对齐。

用 redis.Client.Set 实现分布式锁为什么总失效

因为 Set 默认不带原子性校验，SET key value EX 30 NX 才是正确姿势——Go 的 redis.Client.Set 方法里，NX（仅当 key 不存在时设置）和 EX（过期时间秒级）必须同时传入，否则可能多个实例同时写入成功。

常见错误现象：redis: nil 返回后仍继续执行业务逻辑；或锁未释放导致后续所有请求阻塞。

• Set(ctx, key, value, time.Second*30) 缺少 NX，等价于普通写入，完全不是锁
• 正确写法是 Set(ctx, key, value, &redis.Options{Expire: time.Second * 30, Mode: redis.SetNX})（Mode: redis.SetNX 是 v9+ 写法；v8 用 SetNX 独立方法）
• value 必须唯一（推荐用随机 UUID），否则释放锁时无法判断是否自己加的锁

释放锁时用 DEL 直接删 key 会误删别人持有的锁

因为锁的 value 是持有者身份标识，直接 DEL 不校验 value，A 实例的锁超时自动释放后，B 实例还没执行完，C 实例拿到锁并开始执行，此时 A 恢复过来一通 DEL，就把 C 的锁干掉了。

必须用 Lua 脚本保证“判断 value + 删除”原子执行：

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

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

Go 中调用方式：

• 用 redis.Eval 或 redis.EvalSha 执行上述脚本
• KEYS[1] 传锁 key，ARGV[1] 传当前实例生成的唯一 value
• 返回值为 int64：1 表示删除成功，0 表示非本实例所持，不可删除

在 K8s 多 Pod 场景下，锁续期（renew）比超时时间还慢就必然丢锁

Pod 可能被调度、网络抖动、GC STW 延长，导致心跳续期延迟。如果锁 TTL 是 15 秒，但续期任务每 10 秒跑一次，某次卡到 12 秒才发请求，那剩下 3 秒内只要再卡一次，锁就过期了。

真实场景中，续期间隔必须远小于 TTL，且要预留 buffer：

• TTL 设为 30 * time.Second，续期间隔建议 ≤ 8 * time.Second
• 续期本身也要设超时（如 ctx, _ := context.WithTimeout(context.Background(), 500*time.Millisecond)），避免阻塞主流程
• 不要依赖定时器硬间隔，改用“上一次续期成功后立即计算下次时间”，防止 drift 累积

用 etcd 替代 Redis 做分布式锁时，LeaseID 和 KeepAlive 的生命周期必须对齐

etcd 的租约不是绑定到 key 上的，而是由客户端主动维持；一旦 KeepAlive channel 关闭或 client 断连，租约立刻失效，key 自动删除——这和 Redis 的被动过期完全不同。

容易踩的坑：

• 在一个 goroutine 里调用 c.KeepAlive，但没处理 的 close 或 error，导致续期静默失败
• 把同一个 LeaseID 复用在多个 key 上，一个 key 删除不影响其他，但租约一挂全崩
• 创建 lease 时没设足够长的 TTL（如 LeaseGrant(30)），又没及时 LeaseRenew，比 Redis 更容易丢锁

复杂点在于：K8s 环境下 etcd 集群本身也有网络分区风险，lease 续期失败未必是应用问题，得结合 etcdserver: request timed out 日志交叉判断。