Zookeeper面试题总结

Zookeeper 面试题总结及详细解答

以下是一些常见的 Zookeeper 面试题及详细解答，帮助你更好地准备面试。

1. Zookeeper 是什么？

回答：
Zookeeper 是一个开源的分布式协调框架，主要用于分布式系统中的协调服务。它提供了高效的分布式数据管理能力，包括：

• 同步服务：多个节点之间的数据同步。
• 命名服务：为分布式应用提供一致的命名和配置管理。
• 分布式锁：通过节点的临时性、顺序性特性提供分布式锁功能。
• 集群管理：用于管理分布式系统中的集群状态，确保节点间的协调与一致性。

Zookeeper 使用了 ZAB (Zookeeper Atomic Broadcast) 协议来确保节点间的同步和数据一致性。

2. Zookeeper 的核心概念和原理是什么？

回答：
Zookeeper 的核心概念和原理包括：

1. ZNode：Zookeeper 使用 ZNode 来表示数据节点，类似于文件系统中的文件或目录。每个 ZNode 可以存储数据，也可以有子节点。

   • 持久节点：ZNode 一旦创建，就会一直存在，除非被显式删除。
   • 临时节点：ZNode 只有当客户端与 Zookeeper 的会话存在时才有效，一旦会话关闭，临时节点会自动删除。
   • 顺序节点：ZNode 在创建时会为其自动分配一个递增的编号，通常与临时节点一起使用来实现分布式锁。

2. Leader-Follower 模型：Zookeeper 通过选举一个 Leader 节点来处理所有写请求，其他节点为 Follower，处理读请求。集群内有多个节点，确保高可用性和容错性。

3. Quorum：Zookeeper 使用法定人数（Quorum）机制，保证集群中大多数节点对操作的确认，从而保证数据一致性。通常要求集群中超过半数节点确认某个操作才能认为该操作成功。

4. ZAB 协议：Zookeeper 使用 ZAB 协议保证事务日志的顺序一致性。在 Leader 节点上提交事务请求，所有 Follower 节点需要应用这些事务。

3. Zookeeper 如何保证高可用性和一致性？

回答：
Zookeeper 通过以下方式保证高可用性和一致性：

1. Leader 选举机制：Zookeeper 使用 Leader 节点来协调所有的写操作，这样可以保证数据的一致性。Leader 节点负责写操作，Follower 节点负责读取操作。当 Leader 节点宕机时，集群会通过选举重新选出 Leader。

2. Quorum（法定人数）：Zookeeper 中的操作（特别是写操作）需要得到超过半数节点（Quorum）的确认才能成功。这种机制确保了即使部分节点宕机，系统仍能保持一致性和高可用性。

3. ZAB 协议：Zookeeper 使用 ZAB 协议来保证事务的一致性和顺序性。即使发生节点故障，ZAB 协议也能确保数据恢复和一致性。

4. 持久化机制：Zookeeper 会将所有修改操作记录在事务日志中，通过磁盘持久化操作来防止数据丢失。

4. Zookeeper 的节点类型有哪些？

回答：
Zookeeper 的节点类型包括：

1. 持久节点（Persistent ZNode）：当创建此类节点时，它会一直存在，直到显式删除。即使客户端断开连接，节点仍然存在。

2. 临时节点（Ephemeral ZNode）：临时节点只有在与客户端的会话期间有效。当客户端与 Zookeeper 服务器的连接断开时，临时节点会自动删除。

3. 顺序节点（Sequential ZNode）：顺序节点是持久节点或临时节点的一种扩展，在创建时会为每个节点自动添加一个递增的数字后缀，用于标识该节点的顺序。顺序节点常用于实现分布式锁和任务队列。

5. Zookeeper 集群中，Leader 失效时会发生什么？

回答：
当 Zookeeper 集群中的 Leader 失效时，会发生以下几个步骤：

1. Leader 失效：Zookeeper 集群中的 Leader 节点如果由于网络问题或宕机等原因失效，集群内的 Follower 节点会检测到该故障。

2. Leader 选举：集群内的 Follower 节点会发起 Leader 选举过程。选举过程中，节点会比较彼此的事务日志，并选举出一个新的 Leader。

3. 新 Leader 提交操作：新的 Leader 节点选举出来后，开始处理写请求，并同步给其他 Follower 节点，确保数据一致性。

4. 数据一致性保证：Zookeeper 的选举过程确保集群内的一致性和高可用性，整个过程需要法定人数（Quorum）的节点参与，从而避免了数据不一致的问题。

6. Zookeeper 的使用场景有哪些？

回答：
Zookeeper 常见的使用场景包括：

1. 分布式锁：Zookeeper 的临时顺序节点可以用来实现分布式锁。多个客户端通过创建顺序节点来竞争锁，只有创建最小序号节点的客户端才能获得锁。

2. 配置管理：Zookeeper 提供了一个中心化的配置管理平台，多个分布式应用可以通过 Zookeeper 获取最新的配置信息，避免配置文件的分散和不一致性。

3. 命名服务：Zookeeper 可以用于分布式系统中的服务注册和发现。服务注册时将服务信息写入 Zookeeper，消费者可以通过 Zookeeper 获取服务信息，避免了服务发现的重复操作。

4. 分布式队列：Zookeeper 的顺序节点可用来实现分布式任务队列，通过节点顺序来控制任务的调度和处理。

5. 集群管理：Zookeeper 可以用于集群中节点的管理，如节点的上线、下线、健康检查等。

7. Zookeeper 的常见问题及优化

回答：

1. 单点故障：尽管 Zookeeper 是一个分布式系统，但如果没有正确配置、节点数太少（比如 1 个节点），可能会成为单点故障。需要至少 3 个节点（推荐 5 个节点）来避免单点故障。

2. 性能瓶颈：Zookeeper 本身在处理大量写请求时可能会成为瓶颈，尤其是在数据量较大的情况下。因此，应该尽量减少写请求，尽量通过缓存或异步方式减轻 Zookeeper 的负载。

3. 数据持久性问题：Zookeeper 的数据持久化是通过事务日志进行的，如果系统没有足够的磁盘空间，可能会导致数据丢失。因此，合理配置 Zookeeper 的日志存储目录，并定期清理不必要的日志文件，确保足够的存储空间。

4. 节点故障处理：Zookeeper 需要通过法定人数来维持正常工作，因此节点故障时，应该及时替换或修复节点。可以使用自动化监控工具（如 Zookeeper 自带的 zkServer.sh）进行故障检测和恢复。

8. Zookeeper 和 Etcd 的区别？

回答：
Zookeeper 和 Etcd 都是分布式协调服务，但它们有一些区别：

• 协议：

  • Zookeeper 使用 ZAB 协议保证数据一致性。
  • Etcd 使用 Raft 协议来保证一致性，Raft 相比 ZAB 更容易理解和实现。

• 用途：

  • Zookeeper：广泛用于大规模分布式系统中，提供更多功能，如分布式锁、队列、命名服务等。
  • Etcd：主要用于 Kubernetes 和容器编排系统中，专注于提供可靠的配置管理和服务发现。

• 性能：

  • Etcd 比 Zookeeper 更轻量，适用于大规模容器化环境。
  • Zookeeper 通常用于传统的大规模分布式系统中。

• 易用性：

  • Etcd 更加简单易用，配置和管理更方便。
  • Zookeeper 配置复杂，管理要求较高。

9. Zookeeper 集群的工作原理是怎样的？

回答：
Zookeeper 是一个基于 ZAB 协议（Zookeeper Atomic Broadcast） 的分布式协调服务，其工作原理如下：

1. Leader-Follower 模型：

   • Zookeeper 集群由一个 Leader 节点和多个 Follower 节点组成。
   • 所有的写请求都必须经过 Leader 节点处理，Leader 节点将这些写请求广播到所有的 Follower 节点。
   • 读请求可以由任何一个 Follower 节点处理，除非 Follower 节点尚未同步到最新的数据。

2. ZAB 协议：

   • ZAB 是 Zookeeper 中确保数据一致性的协议。当 Leader 节点接收到写请求时，会先将请求数据写入事务日志，随后将请求数据广播到集群中的 Follower 节点。
   • 当超过半数的节点确认收到了数据并应用了该数据时，Leader 节点才会认为这次写请求成功并提交数据。
   • 如果 Leader 节点宕机，集群会通过 ZAB 协议启动新的 Leader 选举。

3. Quorum（法定人数）：

   • Zookeeper 使用 Quorum（法定人数） 的机制来保证数据一致性。即使部分节点宕机，只要剩下的节点数大于等于半数节点，集群依然能够继续工作。
   • 比如，在一个 5 节点的集群中，至少需要 3 个节点确认操作才能认为该操作是成功的。

4. Leader 选举：

   • Zookeeper 在集群启动时或者 Leader 宕机时，会通过 Leader 选举过程来选出新的 Leader。Zookeeper 使用 ZAB 协议 中的选举算法来确保选举过程的高效和一致性。

5. 数据一致性：

   • Zookeeper 的数据一致性是通过强一致性保证的。所有的写操作都必须经过 Leader 节点，确保操作顺序一致。集群中的所有节点都按照相同的顺序处理数据，以避免出现分裂脑（Split-Brain）等问题。

10. Zookeeper 中的 Watcher 是什么？

回答：
Watcher 是 Zookeeper 提供的一种机制，它允许客户端在 Zookeeper 节点上设置监视器。当节点的数据发生变化（如数据修改、节点删除、子节点变化等）时，Zookeeper 会触发事件通知客户端。Watcher 是单次触发的，即事件触发后，Watcher 会被自动移除。

主要特点：

• 事件类型：可以监视节点的变化，包括：

  • NodeCreated：节点被创建。
  • NodeDeleted：节点被删除。
  • NodeDataChanged：节点的数据发生变化。
  • NodeChildrenChanged：节点的子节点发生变化。

• 单次触发：当指定的事件发生时，Watcher 会触发一次通知。通知触发后，Watcher 会失效，需要客户端重新设置 Watcher 来继续监控该节点。

• 使用场景：常见的使用场景包括配置管理（例如监控配置文件是否改变）、服务发现（如监控服务节点的上线与下线）等。

示例代码：

ZooKeeper zk = new ZooKeeper("localhost:2181", 3000, new Watcher() {
    public void process(WatchedEvent event) {
        // 处理事件
        if (event.getType() == Event.EventType.NodeDataChanged) {
            System.out.println("Data has been changed!");
        }
    }
});

11. Zookeeper 中的事务是如何处理的？

回答：
Zookeeper 使用 事务日志 来保证数据的一致性和持久性。每当有一个写操作时，Zookeeper 会将该操作记录到事务日志中（ZookeeperTransactionLog）。Zookeeper 使用的事务机制是基于日志的，确保系统故障恢复时数据不丢失，并能恢复到一致的状态。

1. 事务执行流程：

   • 客户端发起写请求到 Leader 节点。
   • Leader 节点将请求数据写入事务日志，并将数据广播到 Follower 节点。
   • Follower 节点收到数据后，将数据写入自己的事务日志并确认收到数据。
   • 当超过法定人数（Quorum）节点确认收到数据时，Leader 节点将提交该事务，并将修改应用到本地数据。

2. 日志机制：

   • 所有写操作都记录在事务日志中。这些日志记录了操作的详细信息，可以用于故障恢复。
   • 当系统崩溃时，Zookeeper 会从日志中读取最后的操作，并恢复到一致的状态。

3. 事务的原子性：

   • Zookeeper 保证事务的 原子性，即要么所有操作成功，要么都不成功。当事务提交时，所有节点会同步执行该操作。

12. Zookeeper 如何实现分布式锁？

回答：
Zookeeper 可以通过 临时顺序节点 实现分布式锁。具体过程如下：

1. 创建临时顺序节点：客户端在 Zookeeper 上创建一个临时顺序节点，这个节点会带有一个递增的序号，例如 /lock-0000001、/lock-0000002 等。

2. 竞争锁：多个客户端同时创建临时顺序节点。创建最小序号节点的客户端获取锁。

3. 释放锁：当客户端使用完锁后，会删除自己的节点。删除节点时，Zookeeper 会自动清理临时节点。

4. 监视前一个节点：每个客户端创建节点时，会监视自己前一个节点（即编号比自己小的那个节点）。当前一个节点被删除时，表示锁被释放，客户端可以获取锁。

实现分布式锁的步骤：

• 客户端在 /lock 路径下创建临时顺序节点。
• 客户端检查自己是否是最小编号的节点。如果是，则获取锁。
• 如果不是，客户端监视自己编号较小的节点。一旦该节点删除，客户端尝试重新获取锁。

示例代码（简化版）：

// 创建临时顺序节点
String path = zk.create("/lock-", new byte[0], Ids.OPEN_ACL_UNSAFE, CreateMode.EPHEMERAL_SEQUENTIAL);

// 获取节点序号
String nodeName = path.substring(path.lastIndexOf("/") + 1);
List<String> children = zk.getChildren("/lock", false);
Collections.sort(children);
if (nodeName.equals(children.get(0))) {
    // 获取锁
} else {
    // 监视前一个节点
    String prevNode = children.get(children.indexOf(nodeName) - 1);
    zk.exists("/lock/" + prevNode, new Watcher() {
        public void process(WatchedEvent event) {
            if (event.getType() == Event.EventType.NodeDeleted) {
                // 尝试重新获取锁
            }
        }
    });
}

13. Zookeeper 中的 Session 是如何管理的？

回答：
Zookeeper 使用 会话（Session） 来管理客户端与 Zookeeper 服务端的连接。每个客户端与 Zookeeper 服务器建立连接时，都会分配一个唯一的 Session ID。该 Session 在客户端与 Zookeeper 服务器之间保持连接状态，并用来区分不同的客户端。

1. Session 生命周期：

   • 客户端与 Zookeeper 建立连接时，Zookeeper 会为其分配一个唯一的 Session ID。
   • 如果客户端在指定时间内未能发送心跳或与 Zookeeper 断开连接，Zookeeper 会认为该客户端的会话过期，并删除与该会话相关的所有临时节点。
   • 会话可以设置超时时间，客户端必须定期发送心跳请求以保持会话有效。

2. 临时节点与会话关联：

   • 临时节点是与客户端的 Session 相关联的。如果客户端与 Zookeeper 的连接断开或会话超时，Zookeeper 会自动删除该客户端创建的临时节点。

3. 会话重连：

   • 如果客户端与 Zookeeper 失去连接并恢复连接，它可以使用相同的 Session ID 来恢复会话，保证客户端在重新连接后能够继续操作。

14. Zookeeper 和其他分布式协调系统（如 Etcd、Consul）的区别是什么？

回答：
Zookeeper、Etcd 和 Consul 都是常用的分布式协调系统，它们有以下几点区别：

1. 协议：
   • Zookeeper：使用 ZAB（Zookeeper Atomic Broadcast） 协议来保证数据一致性和事务的顺序性。
   • Etcd：使用 Raft 协议，Raft 比

ZAB 更易理解且被广泛用于 Kubernetes 和容器化系统中。

• Consul：使用 Raft 协议来保证一致性，同时提供健康检查功能和服务发现功能。

2. 功能：

   • Zookeeper：除了基本的协调功能外，Zookeeper 还提供了分布式锁、队列、配置管理等功能，适用于大规模的分布式应用。
   • Etcd：主要用于 分布式配置管理 和 服务发现，并且特别适合与 Kubernetes 等容器管理平台结合使用。
   • Consul：提供 服务发现、健康检查、配置管理 等功能，且更加关注微服务架构。

3. 性能和易用性：

   • Etcd 和 Consul 比 Zookeeper 更轻量、易于部署和管理，适合云原生应用，尤其在容器化环境中表现更好。
   • Zookeeper 配置和管理较为复杂，但功能更为强大，适用于更传统的分布式系统。

15. Zookeeper 中的节点是如何存储数据的？

回答：
Zookeeper 中的每个节点（ZNode）可以存储一定大小的数据。Zookeeper 对 ZNode 的存储方式有如下几方面的要求：

1. 数据存储：

   • Zookeeper 中的每个节点都有一个数据字段，可以存储最多 1MB 的数据。这些数据存储在内存中，并定期持久化到磁盘中。
   • 节点的数据存储具有一致性，所有的节点数据在集群中是同步的。每当 Leader 节点提交一个写操作后，所有的 Follower 节点都会同步更新相同的数据。

2. 数据版本：

   • 每个 ZNode 都有一个版本号，称为 dataVersion。每次修改节点数据时，版本号都会递增。这样，客户端在更新节点数据时可以进行 乐观锁 检查，避免由于并发操作造成的数据丢失或覆盖。

3. 数据的持久化：

   • Zookeeper 在写操作时会先将操作记录到事务日志中（transaction log）。这些日志会被同步到磁盘，确保在系统崩溃后可以恢复数据。
   • Zookeeper 还会使用 快照（snapshot） 来保存节点状态，快照通常会定期生成，可以帮助恢复整个 Zookeeper 集群的状态。

4. 数据一致性：

   • 通过 ZAB 协议，Zookeeper 保证了集群中所有节点的数据一致性。任何写请求都需要通过 Leader 节点处理，Leader 将数据更新广播到所有的 Follower 节点，确保所有节点的数据最终一致。

16. Zookeeper 中如何实现分布式配置管理？

回答：
Zookeeper 提供了一个非常简单高效的分布式配置管理机制。通常，通过 Zookeeper 的 ZNode 存储配置信息，所有参与者（应用程序）都能通过 Watcher 监控配置的变化，来及时更新配置。

实现步骤：

1. 创建配置节点：

   • 配置项可以以键值对的形式存储在 Zookeeper 中。每个配置信息存储在一个 ZNode 下。
   • 例如，假设我们有一个应用需要管理数据库连接信息，可以在 /config/db 下存储配置信息，节点数据可以是 { "host": "localhost", "port": 3306 }。

2. 配置修改监控：

   • 客户端可以在 Zookeeper 上对配置节点设置 Watcher。当配置文件发生变化时，Watcher 会被触发，客户端可以根据新的配置动态调整行为。

3. 配置更新：

   • 配置更新时，管理员只需要修改 ZNode 下的数据，Zookeeper 会确保所有客户端都能够及时获得更新的配置。
   • 这种机制使得配置管理非常灵活，能够支持动态配置变化而无需重启应用。

示例：

• 假设我们的应用程序存储配置文件的路径是 /config/db，我们可以通过如下方式更新配置：

// 设置Watch监听配置
zk.exists("/config/db", new Watcher() {
    public void process(WatchedEvent event) {
        if (event.getType() == Event.EventType.NodeDataChanged) {
            System.out.println("Configuration changed!");
            // 重新加载配置信息
        }
    }
});

// 获取配置
byte[] configData = zk.getData("/config/db", false, null);
String configString = new String(configData, StandardCharsets.UTF_8);
System.out.println("Current Config: " + configString);

通过 Zookeeper 的 Watcher 机制，客户端可以在配置变更时自动更新自己的配置，而无需人工干预。

17. Zookeeper 如何处理节点的同步与数据一致性？

回答：
Zookeeper 的核心设计理念之一就是保证数据一致性。它采用了 ZAB 协议（Zookeeper Atomic Broadcast）来实现节点间的数据同步与一致性，确保所有的 Zookeeper 节点（Leader 和 Follower）都保持一致的数据状态。

ZAB 协议的关键点：

1. Leader 选举：

   • Zookeeper 使用 ZAB 协议来进行 Leader 选举。在集群启动或 Leader 宕机时，Zookeeper 会选举出一个新的 Leader 节点。Leader 节点负责所有写操作，并将写操作同步到 Follower 节点。

2. 写操作的提交：

   • 客户端发送写请求到 Leader 节点，Leader 将写请求记录到事务日志，并将请求广播到集群中的所有 Follower 节点。
   • 当超过法定人数（Quorum）的 Follower 节点确认收到请求并应用数据时，Leader 才会提交该操作并返回给客户端。

3. 数据同步：

   • 当 Leader 节点接收到写请求时，它会将数据同步到所有 Follower 节点。每个节点都会记录这次操作，并保证数据的顺序一致。
   • Follower 节点在收到 Leader 的数据后，会将数据写入自己的内存中，并同时写入事务日志，以保证数据的一致性。

4. 故障恢复：

   • 当节点故障时，Zookeeper 会通过 ZAB 协议确保系统能够迅速恢复，保证数据一致性。宕机的节点会通过日志回放来恢复数据。

5. 保证顺序一致性：

   • Zookeeper 保证每个客户端的操作在集群中的顺序是一致的。这是通过 Leader 统一处理所有写请求并将其广播到 Follower 节点来实现的。

18. Zookeeper 的 CAP 理论分析

回答：
根据 CAP 理论（Consistency、Availability 和 Partition tolerance），分布式系统不能同时满足这三个特性，它最多只能满足其中的两个特性。

• Consistency（数据一致性）：所有节点的数据是一致的。
• Availability（可用性）：每个请求都会收到响应，无论成功与否。
• Partition tolerance（分区容错性）：系统能够处理网络分区的情况，确保系统可以继续工作。

Zookeeper 的 CAP 特性：

• Zookeeper 是一个 CP 系统，它更侧重于 一致性（Consistency） 和 分区容忍性（Partition tolerance）。

  • 在网络分区的情况下，Zookeeper 会选择放弃可用性，保证集群中的数据一致性。也就是说，在发生网络分区时，Zookeeper 会暂停响应客户端的请求，直到分区解决并恢复一致性。

  • 在一个网络分区发生时，Zookeeper 会选择一个半数以上的节点作为 Quorum 来保证操作的提交。分区期间，如果无法达到 Quorum 数量，Zookeeper 会停止提供服务，避免数据不一致的情况。

19. Zookeeper 如何进行性能调优？

回答：
Zookeeper 在高并发环境下的性能是一个常见的问题，特别是在写操作频繁的情况下。Zookeeper 的性能优化可以从以下几个方面进行：

1. 节点数量的优化：

   • Zookeeper 集群的节点数应该是奇数，以确保每次选举时能够选出 Leader。通常推荐使用 3、5、7 等奇数个节点。
   • 集群中的节点数也要适当，根据集群的负载和性能需求来决定，避免过多的节点导致负载过高。

2. JVM 参数优化：

   • Zookeeper 是基于 Java 的应用，JVM 参数对于性能至关重要。通过调整堆内存、垃圾回收策略等，可以提升 Zookeeper 的性能。
   • 适当配置 -Xmx 和 -Xms 参数，以确保 Zookeeper 可以有效利用内存。

3. 磁盘性能优化：

   • Zookeeper 的事务日志是关键的性能瓶颈。通过选择快速的磁盘（如 SSD），可以提高磁盘 I/O 性能，减少延迟。
   • 将事务日志和数据存储分开到不同的磁盘上，以避免竞争资源。

4. 网络优化：

   • 网络延迟对于 Zookeeper 性能影响较大，尤其是集群节点之间的通信。通过优化网络拓扑，减少节点间的网络延迟，提升系统的整体吞吐量。

5. 配置调整：

   • 调整 tickTime、initLimit 和 syncLimit 等配置参数，以优化集群的同步性能。例如，tickTime 是 Zookeeper 集群中每个时间单位的间隔，增大 tickTime 可以减少网络负载，但可能会增加节点恢复的时间。

6. 负载均衡：

   • 在 Zookeeper 集群中，合理分配客户端连接，避免单个节点的压力过大。可以通过负载均衡算法，将客户端连接均匀分配到各个 Zookeeper

节点上。

7. 缓存优化：
   • 客户端可以缓存一些 Zookeeper 中的数据，避免每次都进行网络请求。Zookeeper 提供了 客户端本地缓存 机制，适当使用可以减少频繁的读取请求。

20. Zookeeper 的事务日志和快照机制是如何工作的？

回答：
Zookeeper 使用 事务日志（Transaction Log） 和 快照（Snapshot） 来实现数据持久性和故障恢复。其工作原理如下：

1. 事务日志：

   • 每当 Zookeeper 处理一个写请求时，它会将操作记录到事务日志中。事务日志记录了每个操作的具体内容，用于系统崩溃后恢复数据。
   • 事务日志会持续追加，不会覆盖。每次写操作的记录会依次写入日志文件。

2. 快照机制：

   • 快照是 Zookeeper 定期记录的数据存储状态。快照可以理解为一个完整的备份，记录了 Zookeeper 当前的所有数据状态。
   • 每隔一段时间，Zookeeper 会生成一个快照，包含所有的节点数据和事务日志中未提交的操作。生成快照时，Zookeeper 会停止对外提供服务，以确保数据一致性。

3. 故障恢复：

   • 当 Zookeeper 启动时，它会加载最近的快照文件，然后应用事务日志中的操作，直到恢复到崩溃前的状态。
   • 通过这种方式，Zookeeper 能够在发生故障时快速恢复数据，同时保证数据的一致性。

总结：

Zookeeper 是一个非常强大的分布式协调工具，在许多大规模分布式系统中都有应用。面试时，理解 Zookeeper 的工作原理、数据一致性机制、常见的使用场景和功能实现（如分布式锁）是至关重要的。同时，掌握 Zookeeper 的高可用性保障机制（如 Leader 选举、Quorum）、数据持久性和事务处理等内容也是面试的重点。如果你在面试过程中能清晰地解释这些内容，将帮助你更好地展示自己的技术能力。