etcd选主依赖Lease和CAS组合实现：Lease TTL设10–15秒防假存活，CAS需校验version==0确保首次创建，禁用Put避免覆盖；推荐用concurrency.Election封装，但须监听Observe通道及时退出leader循环。
etcd 的 Lease 和 CompareAndSwap 是选主核心依赖
etcd 本身不提供“选主 API”，必须靠客户端组合 Lease（租约）和 CompareAndSwap（CAS）实现。没租约，主节点挂了没人知道；没 CAS，多个节点可能同时写入 leader key，造成脑裂。
实操建议：
-
LeaseTTL 建议设为 10–15 秒：太短会频繁续租加重 etcd 压力；太长故障发现延迟高 - 写 leader key 必须带
LeaseID，否则租约到期后 key 自动删除，但你不知道——这会导致“假存活” - CAS 操作要检查
version == 0或create_revision == 0，确保只允许第一个节点创建成功，而不是覆盖已有值 - 不要用
Put直接写，它不校验前置条件，会覆盖其他候选人的尝试
Go 客户端用 election 包最省事，但得自己 handle 续租失败
官方 go.etcd.io/etcd/client/v3/concurrency 提供了 election 类型，封装了 lease + CAS + watch，开箱即用。但它不会自动 recover 续租失败——这是线上最常出问题的地方。
常见错误现象：context deadline exceeded 或 lease expired 后，程序仍以为自己是 leader，继续处理请求，引发数据不一致。
实操建议：
- 监听
Election.Observe()返回的chan *concurrency.ElectionResponse，一旦 channel 关闭或收到空响应，立刻退出 leader 工作循环 - 续租 goroutine 要单独起，并用
select { case 判断是否断连 - 每次处理业务前，先调
election.IsLeader()（本质是查 key version），别只信本地状态变量
多个服务实例共用一个 election 实例会冲突
同一个 concurrency.Election 对象不能被多个 goroutine 并发调 Proclaim() 或 Resign()，更不能在不同进程间共享。常见误用是把 election 实例塞进全局变量，然后所有 worker 都去抢——结果是 CAS 失败率飙升，leader 频繁切换。
使用场景：每个服务进程（或每个独立部署单元）应有且仅有一个 election 实例，对应唯一 key，比如 /services/api-leader-001。
实操建议：
- key 路径里带上实例标识，如 hostname 或 pod UID，避免 K8s 下多个副本写同一个 key
- 不要复用 clientv3.Client 连接池里的同一个
concurrency.Session，每个 election 应配独立 session，否则 lease 续期互相干扰 - 启动时加日志输出
election.Key()和session.Lease()，方便排查是否 key 冲突或 lease 重复
watch leader key 变更时，Watch 通道关闭不等于 leader 变更
有人用 client.Watch(ctx, key) 监听 leader key 删除事件来感知失主，但 etcd watch 通道可能因网络抖动、重连、revision gap 而关闭——这不是 leader 变更，只是连接断了。
性能影响：频繁重连 watch 会增加 etcd server 的 watch stream 压力，尤其当集群有上百个服务都在 watch 同一类 key。
实操建议：
- 永远用
election.Observe()（它内部已做 reconnect + revision 恢复），别自己裸写 watch 循环 - 如果非要自建 watch，必须检查
resp.Canceled和resp.Err()，并区分rpc error: code = Canceled（主动 cancel）和context deadline exceeded（超时断连） - watch 启动后第一件事是读一次 key 当前值（
Get），确认初始 leader，避免 watch 启动前就发生的变更被漏掉
真正的难点不在怎么抢主，而在怎么及时、准确地感知自己是不是还活着。租约续不上、watch 断了、CAS 返回旧值却没检查——这些细节一漏，高可用就变成高风险。
