1. 设计定位

ZooKeeper 是一个分布式协调服务。它的出现是为了解决分布式系统中复杂的协调问题，如命名服务、配置管理、分布式锁、集群管理等。它将这些复杂的逻辑封装成简单的 API，让开发者可以专注于业务逻辑。

2. 核心架构 (三大支柱)

我对 ZooKeeper 的理解主要构建在三个核心支柱上：

  1. 数据模型 (ZNode)：
    • 类似文件系统的树形结构，简单清晰。
    • 支持持久、临时、顺序节点，满足了各种协调需求（如临时节点用于服务发现，顺序节点用于分布式锁）。
  2. Watch 机制：
    • 实现了“推拉结合”的通知机制。
    • 让客户端能够实时感知服务端的变化，是实现配置热更和服务治理的关键。
  3. ZAB 协议：
    • 保证了分布式环境下的数据一致性（顺序一致性）和高可用性（崩溃恢复）。

3. 优缺点分析

  • 优点：
    • 高可用：去中心化（虽然有 Leader，但选举快），无单点故障。
    • 严格顺序：保证事务的全局顺序。
    • 高性能：适合读多写少的场景。
  • 缺点：
    • 写性能瓶颈：所有写请求由 Leader 处理，不能水平扩展。
    • 不适合大规模服务发现：在海量微服务场景下，CP 模型会导致注册中心不可用，且大量 Watch 会引发性能问题。

4. 总结

面试官：谈谈你对 ZooKeeper 的理解。

候选人： 我认为 ZooKeeper 是分布式系统的基石。

从功能上讲，它就像一个高可用的分布式文件系统，配合 Watch 监听机制，解决了分布式系统中的“信息同步”和“状态感知”难题。

从架构上讲，它通过 ZAB 协议实现了 CP 模型，优先保证一致性。这使得它非常适合做元数据存储、配置中心和分布式锁。

虽然在超大规模服务发现场景下，它的 CP 特性和写性能瓶颈受到挑战（被 Nacos 等 AP 系统挑战），但在需要强协调和强一致的场景中，ZooKeeper 依然是不可替代的经典方案。