Redis SETNX 不适合直接当分布式锁用，因其缺乏过期机制易致死锁、无身份校验会误删、超时释放引发数据不一致；需结合唯一value、Lua原子校验删除、自动续期等机制才安全。
为什么 Redis SETNX 不适合直接当分布式锁用
直接用 SETNX 加锁看似简单，但会掉进三个坑：锁没设过期时间导致死锁、解锁时不是自己加的锁却被删掉（误删）、网络分区下锁自动过期但业务还没执行完（超时误释放）。这些问题在微服务高频调用场景下极易引发数据不一致。
真正可用的方案必须同时满足：互斥性、防止误删、自动续期能力、可重入（可选）。
-
SET key value EX seconds NX是基础，但 value 必须是唯一标识（如 UUID），后续解锁前要先GET校验 - 不要用
DEL直接删锁，改用 Lua 脚本保证原子性：EVAL "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end" 1 lock_key client_id - 如果业务执行时间不确定，需额外起 goroutine 调用
PEXPIRE续期，或改用 Redlock 或 Redisson 模式
Go 里用 go-redsync 实现带自动续期的 Redis 分布式锁
go-redsync 封装了 Redlock 算法，能缓解单点 Redis 故障问题，且内置租约（lease）机制，支持自动续期和优雅释放。但它默认不校验 client ID，需手动 patch 或配合自定义 redsync.MutexOption 补上身份校验逻辑。
典型用法：
立即学习“go语言免费学习笔记（深入）”；
pool := &redis.Pool{...}
rs := redsync.New(pool)
mutex := rs.NewMutex("resource:42", redsync.WithExpiry(8*time.Second), redsync.WithTries(10))
if err := mutex.Lock(); err != nil {
// 失败
}
defer func() { _ = mutex.Unlock() }() // Unlock 自动做身份校验 + Lua 删除
- 注意
WithExpiry要比预计业务耗时长至少 2–3 秒，否则可能在续期前就过期 - 如果服务启停频繁，建议在
Unlock前加mutex.IsOwned()判断，避免重复释放已过期锁 - Redlock 在多数微服务部署中略显重——若你只有单 Redis 实例，用
redis-go+ 自研 Lua 锁更轻量可控
Etcd 分布式锁：适合强一致性要求高的微服务链路
当你的系统已重度依赖 Etcd（比如用它做服务发现+配置中心），顺手用它实现分布式锁反而更可靠：基于 Raft 协议，天然支持租约（Lease）、监听（Watch）、自动过期，且没有 Redis 的异步复制风险。
核心是 clientv3.Txn + clientv3.LeaseGrant：
leaseResp, _ := cli.Grant(ctx, 5) // 5秒租约
resp, _ := cli.Txn(ctx).If(
clientv3.Compare(clientv3.CreateRevision("lock/key"), "=", 0),
).Then(
clientv3.OpPut("lock/key", "owner-id", clientv3.WithLease(leaseResp.ID)),
).Commit()
if !resp.Succeeded { /* 已被占 */ }
// 后续需另起 goroutine 调用 cli.KeepAlive(ctx, leaseResp.ID) 续租
- Etcd 锁的延迟比 Redis 高（Raft 写入开销），不适合毫秒级抢购类场景
- 务必用
WithLease绑定租约，否则节点宕机后锁不会自动释放 - 解锁不用手动删 key——租约到期后 Etcd 自动清理，但你要确保 keepalive goroutine 不泄露
别忽略锁粒度与业务语义的匹配
很多团队踩坑不是因为锁实现错了，而是锁的 key 设计脱离了业务真实边界。比如订单服务对 order_id 加锁，却在事务里顺手更新了用户积分表——这时该锁其实只保护了订单状态，积分并发写仍可能出错。
- 锁 key 应该对应「最小不可分割的共享资源」，而不是接口路径或服务名
- 跨服务协作时，优先考虑最终一致性 + 补偿事务，而非强行用分布式锁串行化所有步骤
- 高并发下，尝试把锁从「写锁」降级为「读锁 + CAS 更新」，例如用
INCRBY或CompareAndSwap替代全量锁
最麻烦的从来不是怎么加锁，而是怎么判断“这里到底需不需要锁”。
