zookeeper应用场景

ZooKeeper 核心应用场景：分布式系统的协同利器

ZooKeeper 凭借其强一致性、高可用的特性，成为分布式系统中解决协同问题的 “瑞士军刀”。从服务注册发现到分布式锁，从配置管理到集群选举，其应用场景覆盖了分布式架构的诸多核心需求。以下详细解析各场景的实现原理与实践方式。

服务注册与发现（注册中心）

在微服务架构中，服务提供者与消费者需动态感知彼此的存在，ZooKeeper 可通过临时节点和监听机制实现这一功能。

实现原理

服务注册：服务提供者启动时，在 ZooKeeper 的指定路径（如 /services/user-service）下创建临时节点，节点数据为服务地址（如 192.168.1.100:8080）。
- 临时节点特性保证：服务下线（会话失效）时，节点自动删除，无需手动注销。
服务发现：服务消费者启动时，通过 getChildren 获取 /services/user-service 下的所有子节点（即所有服务提供者地址），并监听子节点变化。
- 当服务提供者上下线时，子节点增删触发监听事件，消费者实时更新本地缓存的服务列表。
负载均衡：消费者从服务列表中通过轮询、随机等算法选择一个地址调用，无需依赖第三方组件。

与 Eureka 的对比

特性	ZooKeeper（CP）	Eureka（AP）
一致性	强一致性（Leader 选举期间不可用）	最终一致性（优先保证可用性）
可用性	集群半数以上节点故障时不可用	允许部分节点故障，仍提供服务
适用场景	对一致性要求高的服务（如金融交易）	对可用性要求高的服务（如电商）

分布式锁

分布式系统中，多节点竞争同一资源（如库存扣减、订单创建）时，需通过分布式锁保证操作的原子性。ZooKeeper 基于临时有序节点和监听机制实现高效锁控制。

实现原理（独占锁）

抢锁：所有节点在 /lock 路径下创建临时有序节点（如 /lock/req-0000000001）。
判断锁权：节点创建后，获取 /lock 下的所有子节点，若自身是序号最小的节点，则获取锁。
等待锁：若不是最小节点，监听前一个节点的删除事件（如 /lock/req-0000000000），前节点释放锁后触发事件，重复步骤 2。
释放锁：完成操作后删除自身节点，或会话失效时临时节点自动删除，释放锁资源。

优势

避免死锁：临时节点特性保证节点故障时锁自动释放；
公平锁：通过有序节点实现 “先到先得”，避免饥饿问题。

工具推荐

Curator 框架已封装分布式锁实现（InterProcessMutex），无需重复开发：

InterProcessMutex lock = new InterProcessMutex(client, "/lock");
if (lock.acquire(10, TimeUnit.SECONDS)) { // 尝试获取锁，最多等待10秒
    try {
        // 业务逻辑（如扣减库存）
    } finally {
        lock.release(); // 释放锁
    }
}

集群管理与 Master 选举

分布式集群需实时感知节点状态（上下线），并在主节点故障时自动选举新主节点，ZooKeeper 基于临时节点和有序节点实现这一功能。

集群节点状态感知

集群每个节点启动时，在 /cluster/nodes 下创建临时节点（如 /cluster/nodes/node-1），数据为节点状态（如 “存活”）。
所有节点监听 /cluster/nodes 的子节点变化，当某节点故障（会话失效），其临时节点删除，其他节点通过监听事件感知到变化，更新集群状态。

Master 选举（动态主从切换）

集群节点启动时，在 /cluster/master 下创建临时有序节点（如 /cluster/master/node-0000000001）。
节点创建后，判断自身是否为

1	/cluster/master

下序号最小的节点：

是则成为 Master，负责协调集群任务；
否则监听前一个节点，前节点故障（节点删除）时，重新判断是否为最小节点，直至成为 Master。

案例：HBase 利用 ZooKeeper 选举 HMaster，保证集群始终有一个主节点处理元数据管理。

统一配置管理（配置中心）

分布式系统中，多节点需共享配置（如数据库地址、限流阈值），且配置更新后需实时生效，ZooKeeper 可通过 “发布 - 订阅” 模型实现配置集中管理。

实现原理

配置发布：运维人员在 ZooKeeper 的 /config 路径下创建节点（如 /config/app），存储配置数据（如 db.url=jdbc:mysql://xxx）。
配置订阅：应用启动时，通过 getData 获取 /config/app 的数据，并监听节点数据变化。
动态更新：配置更新时（setData 操作），监听事件触发，应用重新获取数据并刷新本地配置，无需重启服务。

优势

集中管理：配置存储在 ZooKeeper 中，避免分散在各节点的配置不一致问题；
实时生效：无需重启应用即可更新配置，适合高可用场景。

统一命名服务

分布式系统中，需为资源（如服务、节点）分配全局唯一标识，ZooKeeper 可通过持久有序节点生成唯一命名。

实现原理

为资源创建持久有序节点，节点名称自动追加全局唯一序号（如 /resource/id-0000000001），确保跨节点的唯一性。
适用于分布式 ID 生成（如订单号、日志 ID）、服务实例唯一标识等场景。

分布式队列

ZooKeeper 基于持久有序节点可实现 FIFO（先进先出）的分布式队列，保证多节点生产 / 消费消息的顺序性。

实现原理

入队：生产者在 /queue 下创建有序节点（如 /queue/task-0000000001），节点数据为任务内容。
出队：消费者监听 /queue 的子节点变化，按序号从小到大处理任务，完成后删除节点。
阻塞队列：若队列无任务，消费者监听 /queue 的子节点新增事件，有新任务时触发处理。