1.ZooKeeper 分布式锁怎么实现的？
ZooKeeper 是一个高效的分布式协调服务，常用于实现分布式系统中的配置管理、命名服务、分布式锁等。下面简要介绍如何使用 ZooKeeper 实现分布式锁。
分布式锁的特性
在讨论如何实现之前，先了解分布式锁应具备的特性：
- 互斥性：同一时刻只能有一个客户端持有锁。
- 可见性：所有客户端都能看到最新的锁状态。
- 容错性：即使有部分节点失败，锁机制仍然能正常工作。
- 死锁避免：系统设计应该尽量避免死锁情况的发生。
使用 ZooKeeper 实现分布式锁
创建临时顺序节点
- 加锁：当一个客户端想要获取锁时，它会在 ZooKeeper 的某个预先约定好的目录下创建一个临时顺序节点（ephemeral sequential node）。因为是顺序节点，所以每个节点都会被分配一个全局唯一的递增序号。
- 检查前序节点：创建完节点后，客户端会获取该目录下的所有子节点列表，并检查自己创建的节点是否是当前最小序号的节点。如果是，则认为成功获得了锁；如果不是，则监听比自己小的那个节点的变化（等待其删除事件）。
- 等待锁释放：如果客户端发现前面还有其他节点，那么它将进入等待状态，直到前一个节点被删除（即前一个锁被释放），这时再重新检查是否可以获得锁。
释放锁
- 当业务逻辑执行完毕或者客户端异常退出时，由于创建的是临时节点，所以一旦客户端与 ZooKeeper 断开连接（例如客户端崩溃或主动断开），ZooKeeper 会自动删除这个节点，从而释放锁。
- 如果客户端正常执行完业务逻辑并打算主动释放锁，它可以显式地删除自己创建的节点。
处理会话失效
- 客户端必须处理好会话失效的情况，因为这可能导致锁丢失。通常需要结合 ZooKeeper 的 Watcher 机制和会话心跳来确保客户端的状态同步和及时响应。
通过这种方式，多个客户端可以安全地竞争同一把锁，并且保证了锁的正确性和高可用性。需要注意的是，实际应用中还需要考虑更多细节问题，比如网络分区、时钟偏差等，以确保分布式锁的健壮性。
2.了解Zookeeper的系统架构吗？
ZooKeeper 是一个分布式协调服务，它为分布式应用提供了一套简单而强大的原语。它的系统架构设计用于在分布式环境中提供高可用性和可靠性。以下是 ZooKeeper 的主要架构组件和工作原理：
ZooKeeper 架构组件
Leader:
- 在一个 ZooKeeper 集群中，有一个服务器被选举为 Leader。
- Leader 负责处理所有的写请求（更新操作），并将其复制到集群中的其他服务器（Follower）。
- 写操作只有在大多数服务器确认后才会成功。
Follower:
- Follower 服务器接收来自客户端的读请求，并返回结果给客户端。
- 它们也参与 Leader 发起的选举过程。
- 接收来自 Leader 的消息，并向 Leader 发送投票。
Observer:
- Observer 类似于 Follower，但不参与选举也不参与写操作的投票。
- 这意味着 Observer 可以减轻集群的负载，因为它只处理读请求。
- Observer 不会影响写操作的法定人数（quorum），即不影响写操作的成功条件。
Client:
- 客户端连接到 ZooKeeper 集群来执行各种操作，如创建节点、删除节点、获取节点数据等。
- 客户端通常会与其中一个服务器保持长连接。
工作流程
- 选举机制 (Leader Election): 当启动一个新的 ZooKeeper 集群或者 Leader 失效时，ZooKeeper 使用一种称为"Fast Leader Election"（ZAB协议的一部分）的算法来选出一个新的 Leader。
- 写操作 (Write Operations): 所有写操作必须通过 Leader 来进行。Leader 会将这些操作广播给所有的 Follower 和 Observer。只有当超过半数的服务器确认了这个写操作，这个操作才会被认为已经提交。
- 读操作 (Read Operations): 读操作可以直接由任何 Follower 或 Observer 处理，不需要 Leader 的介入，因此它们可以快速响应读请求。
- 法定人数 (Quorum): ZooKeeper 需要确保至少有一半以上的服务器正常运行才能正确地处理写操作。这意味着如果集群中有 N 台机器，那么最多可以容忍 (N-1)/2 台机器故障而不影响服务。
数据模型和层次命名空间
ZooKeeper 提供了一个类似文件系统的层次化命名空间，其中的数据单元被称为 znode。每个 znode 可以存储少量的数据（最大为 1MB），并且可以有子 znode。这种结构非常适合用来表示配置信息、状态信息等。
稳定性保证
ZooKeeper 设计的一个关键特性是其对顺序性的保证：所有更新都是全局有序的，这对于实现诸如分布式锁等一致性服务非常重要。
综上所述，ZooKeeper 的架构设计使得它能够在一个分布式环境下提供可靠的协调服务，同时支持高可用性和容错性。
3.Zookeeper为什么要这么设计？
ZooKeeper 的设计决策是为了满足分布式系统中协调服务的特定需求，其设计哲学和架构选择旨在解决一致性、可靠性、性能以及可扩展性等问题。以下是 ZooKeeper 采用这种设计的主要原因：
1. 强一致性
- ZooKeeper 被设计为提供严格的顺序一致性，这意味着所有的客户端看到的数据更新都是按照全局一致的顺序进行的。这对于实现分布式锁、选举领导者等需要严格一致性的场景非常重要。
- 通过使用 ZAB (ZooKeeper Atomic Broadcast) 协议来保证所有服务器对状态变更达成一致，确保了即使在部分服务器故障的情况下，也能保持数据的一致性。
2. 高可用性和容错性
- ZooKeeper 是一个分布式的系统，它允许集群中的某些节点失败而不影响整体服务的可用性。这通过法定人数（quorum）机制实现，即只要超过一半的节点是活跃的，那么整个系统就可以继续工作。
- 使用 Leader-Follower 架构，Leader 负责处理写请求，Follower 和 Observer 可以分担读请求，提高系统的可用性和负载均衡能力。
3. 简单性
- ZooKeeper 提供了一个简单的 API 和类似文件系统的层次化命名空间，使得开发者可以更容易地理解和使用。这样的抽象层简化了复杂分布式应用的开发。
- 简化的模型也有助于减少潜在的错误来源，并且让 ZooKeeper 本身更加稳定可靠。
4. 性能优化
- ZooKeeper 通过将读操作分散到 Follower 和 Observer 上来减轻 Leader 的负担，从而提高了读取性能。
- 写操作虽然需要通过 Leader 并等待多数派确认，但是一旦提交，它们就会被快速传播给其他节点，保证了良好的写入性能。
5. 事件驱动的通知机制
- ZooKeeper 支持 Watcher 机制，允许客户端监听某个 znode 的变化并在变化发生时得到通知。这种事件驱动的方式减少了轮询带来的开销，提高了效率。
6. 持久性和临时节点
- ZooKeeper 支持创建持久节点（Persistent node）和临时节点（Ephemeral node），后者在创建它的会话结束时自动删除。这为实现诸如分布式锁等功能提供了便利，因为当拥有锁的进程崩溃后，锁可以自动释放。
综上所述，ZooKeeper 的设计是为了在复杂的分布式环境中提供一个可靠的、高效的协调服务。它特别适合那些需要严格一致性和高可用性的应用场景，如分布式配置管理、命名服务、集群管理和分布式锁定等。
4.你知道Zookeeper中有哪些角色？
在 ZooKeeper 中，集群内的服务器可以扮演几种不同的角色，这些角色对于实现其高可用性和一致性至关重要。以下是 ZooKeeper 中的主要角色：
- Leader
- 职责：在一个 ZooKeeper 集群中，只有一个 Leader 角色。Leader 负责处理所有的写请求，并将这些更改广播给其他服务器（Follower 和 Observer）。Leader 还负责协调选举过程。
- 特点：所有更新操作都必须通过 Leader 来完成，以确保数据的一致性。只有当大多数的 Follower 或 Observer 确认了写操作后，该操作才会被认为已经提交。
- Follower
- 职责：Follower 参与 Leader 的选举过程，并接收来自 Leader 的消息和状态更新。它们也能够直接处理客户端的读请求。
- 特点：Follower 是集群中的主要工作成员之一，它们参与法定人数投票（quorum），这意味着它们对写操作的成功与否有决定权。如果一个写操作得到了超过半数 Follower 的确认，则认为该操作成功。
- Observer
- 职责：Observer 类似于 Follower，但不参与选举也不参与写操作的投票。因此，它们不会影响法定人数的计算。
- 特点：Observer 主要用来增加系统的读取容量，因为它们也可以处理读请求。这有助于分担 Leader 和 Follower 的负载，特别是在大型集群中。
- Client
- 职责：虽然 Client 不是 ZooKeeper 集群的一部分，但它是一个重要的组成部分，因为它代表了使用 ZooKeeper 服务的应用程序或用户。客户端连接到 ZooKeeper 集群来执行各种操作，如创建节点、删除节点、获取节点数据等。
- 特点：客户端通常会与其中一个服务器保持长连接，并且可以通过 Watcher 监听特定事件的变化。
- Election Participant (选举参与者)
- 职责：这个不是一种独立的角色，而是指那些参与 Leader 选举过程的服务器，即所有的 Follower 和潜在的新的 Leader。
- 特点：在选举期间，每个服务器都会尝试成为新的 Leader，或者为另一个合适的候选者投票。
- Learner
- 职责：这是对 Follower 和 Observer 的统称，表示那些从 Leader 学习最新状态的服务器。
- 特点：Learner 接收来自 Leader 的更新，并将其应用到自己的状态上，以保持与集群其余部分同步。
总结来说，ZooKeeper 的角色设计是为了确保系统能够在分布式环境中提供高效、一致的服务，同时保证高可用性和容错能力。每个角色都有其特定的任务，共同协作以维护整个系统的健康运行。
5.你熟悉Zookeeper节点ZNode和相关属性吗？
ZooKeeper 的核心概念之一是 ZNode，即 ZooKeeper 节点。每个 ZNode 都可以存储数据，并且可以拥有子节点，形成一个层次化的命名空间，类似于文件系统。但是，与传统文件系统不同的是，ZooKeeper 的设计更注重于协调服务和配置管理等场景。以下是关于 ZNode 及其相关属性的详细介绍：
ZNode 类型
- 持久节点 (Persistent node)
- 创建后一直存在，直到显式删除。
- 临时节点 (Ephemeral node)
- 依赖于创建它的会话（session）。如果会话结束（如客户端断开连接），该节点会被自动删除。
- 注意：临时节点不能有子节点。
- 持久顺序节点 (Persistent Sequential node)
- 创建时会在节点名称后面追加一个全局唯一的递增序号。
- 持久存在，除非被显式删除。
- 临时顺序节点 (Ephemeral Sequential node)
- 具有临时节点的特点，同时也会在节点名称后追加一个唯一递增序号。
ZNode 属性
- dataLength: 存储在这个 ZNode 上的数据大小（以字节为单位）。ZooKeeper 对单个 ZNode 数据大小有限制，默认最大为 1MB。
- ctime: 表示这个 ZNode 第一次被创建的时间戳。
- mtime: 最近一次更新 ZNode 数据或元数据的时间戳。
- version: 记录了 ZNode 数据被修改的次数。每次数据变更时版本号都会增加。
- cversion: 子节点变化的版本号。每当一个子节点被添加、删除或重命名时，此版本号就会递增。
- aversion: ACL（访问控制列表）的变化版本号。每当 ACL 被修改时，这个版本号就会增加。
- ephemeralOwner: 如果这是一个临时节点，则该字段表示创建它的会话 ID。对于非临时节点，这个值为 0。
- data: ZNode 中存储的实际数据内容。
- children: ZNode 的直接子节点列表。
特殊特性
- Watcher: 客户端可以在 ZNode 上设置 Watcher 来监听特定事件（例如节点创建、删除、数据变化等）。一旦这些事件发生，ZooKeeper 会通知设置了 Watcher 的客户端。
- ACLs (Access Control Lists): 提供了一种机制来控制哪些用户或应用程序可以对某个 ZNode 进行读写操作。ACLs 是基于 scheme 和 id 的权限控制系统。
通过上述特性和属性，ZooKeeper 提供了一个强大而灵活的基础架构，适用于构建分布式应用中的协调服务，如配置管理、命名服务、分布式锁、集群管理和领导者选举等。