ZooKeeper 是一个开源的分布式协调服务，主要用于解决分布式系统中多个节点之间的 "一致性问题"，比如如统一配置管理、服务注册发现、分布式锁、集群选举等场景。简单说，它就像分布式系统中的 "大管家"，让多个节点能高效协作，避免混乱。
为什么需要 ZooKeeper？
分布式系统由多个独立节点组成（比如微服务集群、大数据集群），节点间需要协同工作，但会面临很多问题：
- 如何让所有节点使用统一的配置（比如数据库地址变更时，所有节点同步更新）？
- 服务 A 需要调用服务 B，如何知道服务 B 的所有节点地址（服务注册与发现）？
- 多个节点同时操作一份数据，如何避免冲突（分布式锁）？
- 集群主节点故障时，如何自动选举新主节点（高可用）？
ZooKeeper 提供了一套简单易用的接口，帮分布式系统解决这些 "协调" 问题，让开发者无需重复实现复杂的一致性逻辑。
ZooKeeper 的核心特性
- 分布式一致性：通过 ZAB（ZooKeeper Atomic Broadcast）协议，保证多个节点数据的一致性（所有节点看到的数据相同）。
- 高可用：自身通常以集群模式部署（至少 3 个节点），少数节点故障不影响整体服务，支持自动故障转移。
- 数据模型简单 ：采用类似文件系统的 "树形结构" 存储数据（称为 ZNode），每个 ZNode 可存储少量数据（默认最大 1MB），适合存配置、地址等轻量信息。
- 例：
/services/user-service节点存储用户服务的所有实例地址。
- 例：
- 监听机制（Watch） ：客户端可监听某个 ZNode 的变化（如数据修改、子节点增减），当变化发生时，ZooKeeper 会主动通知客户端，实现 "实时感知"。
- 例：服务 B 节点下线时，
/services/B的子节点减少，监听该节点的服务 A 会立即收到通知，不再向其发送请求。
- 例：服务 B 节点下线时，
典型应用场景
-
服务注册与发现 ：服务启动时，在 ZooKeeper 中创建一个临时节点（如
/services/order-service/192.168.1.100:8080），服务消费者通过监听/services/order-service节点，获取所有可用服务实例地址，实现动态调用。 -
统一配置管理 ：将系统的全局配置（如数据库账号、限流阈值）存放在 ZooKeeper 的某个 ZNode 中（如
/config/app），所有节点启动时从该节点读取配置，并监听变化。当配置更新时，ZooKeeper 通知所有节点同步新配置，避免逐个节点修改。 -
分布式锁：多个节点竞争资源时，通过在 ZooKeeper 中创建 "唯一临时节点" 实现锁机制：只有成功创建节点的节点能获得锁，其他节点等待；锁释放（节点删除）后，等待节点重新竞争，避免并发冲突。
-
集群选举：分布式集群（如 Hadoop、Kafka）中，通过 ZooKeeper 实现主节点（Leader）选举：所有节点尝试创建同一个临时节点，成功创建者成为 Leader；Leader 故障后节点自动删除，其他节点重新选举。
ZooKeeper 集群架构
ZooKeeper 通常以集群（Ensemble）形式部署，核心角色包括：
- Leader：负责处理写请求、协调集群一致性，是集群的 "主节点"。
- Follower：处理读请求，参与 Leader 选举和写请求的投票（ZAB 协议）。
- Observer（可选）：只处理读请求，不参与选举和投票，用于扩展读性能（适合读多写少场景）。
集群节点数需为奇数（3、5、7 等），确保选举时能产生多数票（如 3 节点集群，2 票即可当选 Leader），提高容错能力（3 节点集群最多容忍 1 个节点故障）。
总结
ZooKeeper 是分布式系统的 "基础设施"，它通过简单的接口提供了可靠的一致性服务，让开发者能专注于业务逻辑，而非分布式协调细节。在微服务、大数据、分布式存储等领域被广泛使用（如 Dubbo 用它做服务注册、Kafka 用它做集群管理）。
如果需要了解具体操作（如 ZooKeeper 集群搭建、用 API 实现分布式锁），可以进一步说明场景～