ZooKeeper实现自动主备选举的核心是利用其临时节点、Watcher和原子创建特性在业务层构建选主逻辑。1. 部署奇数节点ZK集群并集成客户端（如Curator）；2. 推荐使用Curator的LeaderLatch自动管理临时顺序节点选举；3. 手动实现需原子创建临时节点并监听删除事件；4. 注意避免复用内部节点、确保状态同步、处理会话异常及真实故障测试。
用 ZooKeeper 实现自动主备选举，核心不是“配置 ZooKeeper 本身”，而是利用它已有的特性（临时节点 + Watcher + 原子创建）在业务层搭建一套轻量、可靠的选主逻辑。ZooKeeper 集群本身已内置 Leader 选举（Zab 协议），但那是为 ZooKeeper 自身服务的；你要做的是让自己的应用服务基于 ZooKeeper 协调出一个“业务主节点”。
1. 准备 ZooKeeper 集群与客户端
确保已有可用的 ZooKeeper 集群（推荐 3 或 5 节点，奇数台）。应用需集成客户端，如：
- Java 项目常用 Curator Framework（Apache 官方推荐，封装了重试、连接管理、选举等）
- Python 项目可用 Kazoo
- Go 项目可用 zookeeper-go 或 go-zk
以 Curator 为例，Maven 引入：
```xml<dependency>
<groupId>org.apache.curator</groupId>
<artifactId>curator-recipes</artifactId>
<version>5.6.0</version>
</dependency>
```
2. 使用 Curator 的 LeaderLatch 实现简易主备
这是最常用、最稳妥的方式，无需自己写节点监听和竞争逻辑：
- 所有服务实例启动时，创建同一个 LeaderLatch 实例，指定相同路径（如
/leader/election） - Curator 自动在该路径下创建临时顺序节点，并监控节点变化
- 第一个成功创建并获得最小序号节点的服务成为 Leader；其余为 Standby
- Leader 挂掉（会话断开）后，Curator 自动触发重新选举，下一个最小序号节点立即晋升
代码片段（Java）：
```javaLeaderLatch latch = new LeaderLatch(client, "/leader/election", "server-001");
latch.start();
latch.await(); // 阻塞直到成为 Leader
// 此处开始执行主节点逻辑：启动定时任务、开放管理端口、接管调度等
```
3. 手动实现（适合理解原理或定制化强的场景）
若需完全掌控流程（比如要记录主节点元数据、支持权重、兼容旧协议），可手动操作 ZNode：
- 约定主节点路径：
/master，只允许存在一个临时节点（如/master/instance-A） - 每个服务启动时尝试
createEphemeral("/master")—— 利用 ZooKeeper 的原子性，仅一人成功 - 创建失败者，对
/master注册 Exists Watcher，监听其被删除事件 - 一旦监听到删除，立刻重试创建；成功者加载状态、对外提供服务；失败者继续监听
- 务必设置合理的 sessionTimeout（建议 10–30 秒），避免网络抖动误切，也避免故障恢复过慢
4. 注意事项与避坑点
实际落地时，这几个细节常被忽略但影响稳定性：
- 不要复用 ZooKeeper 自身的 /zookeeper/leader 节点——那是 ZK 内部状态，不对外暴露，也不保证语义一致
- 主节点切换后，必须完成状态同步再对外服务（例如从 DB 或共享存储加载最新配置、恢复未完成任务）
- 客户端需处理连接丢失（ConnectionLossException）和会话过期（SessionExpiredException），并重建 LeaderLatch 或重连逻辑
- 若服务有状态（如内存缓存、本地队列），主备间需额外设计状态迁移机制，ZooKeeper 不负责数据同步
- 测试时模拟主节点 kill -9 和网络隔离（如 iptables DROP），比单纯 stop 更真实
