Redis SETNX 不足以支撑生产级分布式锁，因其缺乏自动释放、防误删、续期和死锁处理能力；需结合唯一token、Lua原子删除、超时机制及租约管理，或改用Etcd的Lease+CAS实现更可靠的云原生锁。
为什么 Redis SETNX 不足以支撑生产级分布式锁
直接用 SETNX 加锁看似简单，但会遇到锁不自动释放、无法续期、客户端崩溃导致死锁、误删他人锁等严重问题。真正可用的分布式锁必须满足：互斥性、防误删（通过唯一 token）、超时自动释放、支持可重入或至少明确的锁续约机制。
Go 生态中主流选择是基于 Redis 的 redlock 算法或更轻量的单节点安全实现（如 redis-go 官方推荐的 SET key value EX seconds NX 原子操作 + Lua 脚本校验删除）。Kubernetes 场景下则倾向结合 Etcd 的 CompareAndSwap（CAS）原语——它天然支持租约（lease）和监听，比 Redis 更适合云原生控制平面。
用 go-redis 实现带租约与原子删除的 Redis 分布式锁
推荐使用 github.com/redis/go-redis/v9，避免老版本 redigo 或已归档的 gomodule/redigo。关键不是“怎么加锁”，而是“怎么安全删锁”——必须用 Lua 脚本保证 GET + DEL 原子性，且只删自己持有的 token。
- 加锁用
SET key token EX seconds NX，其中token是随机 UUID（用github.com/google/uuid生成），确保唯一性 - 解锁必须通过 Lua 脚本：
if redis.call("get", KEYS[1]) == ARGV[1] then return redis.call("del", KEYS[1]) else return 0 end - 锁续期需另起 goroutine 定期调用
EXPIRE，但仅当当前 token 仍存在（即未被其他客户端覆盖）——这需要先GET校验再EXPIRE，非原子，所以更适合用支持租约的 Etcd
用 go.etcd.io/etcd/client/v3 实现云原生级分布式锁
Etcd 的 Lease + CompareAndSwap 是 Kubernetes 原生采用的锁机制，天然解决自动过期、跨进程可见、强一致性问题。不需要自己拼 token 和 Lua 脚本，出错率更低。
立即学习“go语言免费学习笔记（深入）”；
核心逻辑：
- 创建一个带 TTL 的
Lease（如 15 秒），获取leaseID - 用
client.KV.Put(ctx, lockKey, "owned", clientv3.WithLease(leaseID))尝试写入锁键 - 用
client.KV.CompareAndSwap(ctx, lockKey, clientv3.Compare(clientv3.Value(lockKey), "=", "owned"), clientv3.OpPut(lockKey, "owned", clientv3.WithLease(leaseID)))判断是否抢锁成功 - 抢锁失败时监听该 key 变更（
client.Watch(ctx, lockKey)），等待释放后重试
注意：Etcd 锁不支持“可重入”，同一 client 多次加锁需自行维护本地计数；且 Watch 事件可能丢失，建议配合短周期轮询兜底。
别忽略锁粒度与业务超时的对齐
无论选 Redis 还是 Etcd，锁的 TTL 必须显著大于业务处理最大耗时（建议 ≥ 3 倍），否则锁提前过期会导致并发冲突。但也不能设得过大——比如设成 1 小时，一旦持有锁的 Pod 意外终止，其他实例要等一小时才能恢复。
更稳妥的做法：
- 业务处理前设置 context deadline，例如
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second) - 锁 TTL 设为 15 秒，同时启动一个独立 goroutine 每 5 秒续期一次 lease（Redis 需额外 GET+EXPIRE 校验；Etcd 可直接
client.Lease.KeepAliveOnce()） - 在 defer 中显式释放锁，而非依赖 TTL——这才是“锁生命周期可控”的关键
真正难的不是实现一个能跑起来的锁，而是让锁的生命周期、错误重试、监控告警和业务超时全部对齐。很多线上故障，都卡在“以为锁释放了，其实没删掉”或者“续期失败却没感知”。
