Golang用Etcd实现分布式锁与选主方法

本文深入剖析了在Golang中基于etcd实现高可靠分布式锁与选主机制的核心原理与实战要点：指出裸Put+Delete无法保障锁安全，必须依托Lease绑定TTL并结合PrevKV与Txn实现原子性CAS加锁与条件删除；强调选主需优先选用clientv3.Session配合短TTL与高频续租，并监听Done()做降级处理；澄清etcd官方Lock API虽便捷但存在全局lease共享风险，多场景下仍需手写独立lease逻辑；全文贯穿“唯一value标识所有权”“避免轮询改用Watch”“释放必走CAS”“panic与网络抖动下的状态兜底”等关键实践原则，为构建稳定、低延迟、容错强的分布式协调系统提供扎实的技术指南。

etcd 分布式锁为什么不能直接用 Put + Delete 模拟

因为 etcd 的租约（lease）和键值原子性是锁安全的唯一基础，裸 Put 没有超时自动释放能力，节点崩溃后锁永远卡死；裸 Delete 无法判断“谁删的”，容易出现 A 删了 B 的锁、B 还以为自己持有锁的竞态。

正确做法必须绑定 LeaseGrant 创建带 TTL 的 lease，再用 Put 的 LeaseID 和 PrevKV 选项实现「仅当 key 不存在时写入」——这靠的是 etcd 的 Compare-and-Swap（CAS）语义。

• Put 必须传 leaseID，否则锁不会自动过期
• 加锁要检查 resp.PrevKv == nil，而不是只看 err == nil
• 不要用 Get 判断 key 是否存在再 Put：中间窗口期会导致两个客户端同时认为“没人占着”

选主（leader election）用 Session 还是手动续租

clientv3.Session 封装了 lease 自动续期和失效监听，对选主场景更稳；但它的底层仍是定期调用 LeaseKeepAlive，一旦网络抖动或 GC 停顿导致续租延迟超过 TTL，session 就会过期，触发误切换。

生产环境建议用 Session，但必须配合短 TTL（如 5s）+ 高频心跳（续租间隔 ≤ TTL/3），并监听 Session.Done() 做降级处理。

• TTL 设为 3–10 秒之间，太短增加 etcd 压力，太长故障恢复慢
• 不要依赖 Session.Orphan() 自动清理：它只在 client 正常关闭时生效，崩溃不触发
• 选主成功后，需立即用 Watch 监听该 key 的 delete 事件，而非轮询

分布式锁的释放为什么必须用 CompareAndDelete

释放锁不是简单 Delete，因为可能被其他节点抢先抢到了锁，此时删掉的是别人的锁。必须确认「当前 value 等于自己当初设的 value」才能删——etcd 不支持原生 value 比较删除，得用 Txn 实现 CAS 删除。

典型错误是把锁 value 设成固定字符串（如 "locked"），这样所有客户端 value 相同，根本没法区分 ownership。

• 加锁时 value 必须唯一，推荐用随机 uuid 或 os.Getpid() + nanotime
• 释放逻辑必须走 Txn().If(...).Then(...)，条件是 cmp.Value("expected_value") == true
• 不要在 defer 中无条件 Delete：panic 后没执行到 defer，或者 panic 恢复后又执行了一次

etcd v3.5+ 的 Lock API 能直接用吗

能，clientv3.NewLocker 提供了封装好的 Lock/Unlock，底层就是基于 lease + txn + watch，省去手写 CAS 的麻烦。但它默认使用全局 lease（所有锁共享一个 lease ID），一旦 lease 过期，所有锁同时失效——这不是 bug，是设计取舍。

如果你的应用里多个锁生命周期不同（比如一个服务既做定时任务调度又管配置热更新），混用 NewLocker 可能导致非预期的锁批量丢失。

• 单服务单用途场景（如纯选主），直接用 NewLocker 安全省心
• 多锁共存且 TTL 需求不一致时，宁可手写带独立 lease 的锁逻辑
• 注意 NewLocker 的 Lock 方法会阻塞直到抢到锁，超时不抛错而是返回 context cancel error，得自己判

今天关于《Golang用Etcd实现分布式锁与选主方法》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！