Zookeeper 面试题（二）

1. 简述Zookeeper基本数据模型和存储结构 ？

Apache ZooKeeper是一个为分布式应用提供一致性服务的软件，它使用一个简单的数据模型来存储和管理数据。以下是ZooKeeper的基本数据模型和存储结构的简述：

基本数据模型：

1. ZNode：ZooKeeper使用ZNode（节点）来存储数据。每个ZNode都类似于文件系统中的一个文件或目录，并且可以包含数据和子节点。

2. 数据版本：每个ZNode都有一个版本号，包括创建版本号和数据版本号。这有助于ZooKeeper保持数据的一致性，并实现原子性更新。

3. 顺序节点：ZooKeeper允许创建顺序节点，这些节点在创建时会被自动赋予一个唯一的序列号。

4. 持久性：ZNode可以是持久的或临时的。持久节点在创建它们的会话结束之后仍然存在，而临时节点在会话结束时会被自动删除。

5. ACL（访问控制列表）：ZooKeeper支持对每个ZNode设置访问权限，确保只有授权的用户或服务可以访问或修改数据。

存储结构：

1. 树形结构：ZooKeeper的数据存储结构是一个分层的树形结构，从根节点(“/”)开始，可以有多个子节点。

2. 路径：每个ZNode都有一个唯一的路径，类似于文件系统中的文件路径。

3. 数据存储：ZNode可以存储少量的数据（默认情况下，每个ZNode的数据大小限制为1MB）。

4. Watcher机制：ZooKeeper支持Watcher机制，允许客户端注册Watcher来监听ZNode的变化，如数据更新或子节点的添加/删除。

5. 事务日志：为了确保数据的一致性和持久性，ZooKeeper会将所有事务操作记录到事务日志中。

6. 内存数据库：ZooKeeper使用内存数据库来存储ZNode数据，以提供快速的数据访问。

7. 快照：ZooKeeper会定期将内存中的数据快照保存到磁盘，以防止内存数据的丢失。

8. 集群模式：在集群模式下，ZooKeeper的数据会被复制到多个服务器上，以提供高可用性和容错能力。

ZooKeeper的数据模型和存储结构设计得非常简单和高效，使得它非常适合用于分布式协调和配置管理等场景。

2. Zookeeper客户端与服务端之间的的连接称之为什么？

ZooKeeper客户端与服务端之间的连接通常称为会话(Session)。

在ZooKeeper中，会话(Session)是客户端与服务器之间建立的一条TCP连接。客户端通过会话与ZooKeeper服务器进行通信，执行数据读写、节点监控等操作。会话具有以下特点：

1. 持久性：客户端可以指定会话的持久性，持久会话在客户端与服务器断开连接后仍然保持有效，直到客户端显式关闭会话或会话超时。

2. 临时性：临时会话在客户端与服务器断开连接时自动结束。

3. 会话ID：每个会话都有一个唯一的会话ID，用于标识客户端与服务器之间的连接。

4. 超时机制：会话具有超时机制，如果客户端在超时时间内没有与服务器进行通信，会话将自动结束。

5. 心跳检测：客户端通过会话定期向服务器发送心跳以保持连接的活跃状态。

6. 权限控制：会话可以携带客户端的认证信息，用于访问控制。

7. Watcher注册：客户端可以在会话中注册Watcher，用于监听ZNode的变化。

8. 事务操作：客户端通过会话向服务器发起事务操作，如创建、删除ZNode，更新ZNode数据等。

会话是ZooKeeper中非常重要的概念，它为客户端提供了一种稳定、可靠的机制来与服务器进行通信和协调。通过管理会话，ZooKeeper可以确保数据的一致性和可靠性，同时提供灵活的客户端连接管理。

3. 简述Zookeeper的watcher机制 ？

Zookeeper是一个分布式协调服务，它提供了一种机制来帮助分布式应用来维护配置信息、命名、提供分布式同步和提供组服务等。Zookeeper的watcher机制是其核心特性之一，它允许客户端在特定的数据节点上注册一个watcher，当这些节点的数据发生变化时，Zookeeper会通知所有注册了watcher的客户端。

以下是Zookeeper watcher机制的一些关键点：

1. 事件驱动：Zookeeper的watcher是基于事件的。当客户端对某个节点注册了watcher，它就会开始监听这个节点的特定事件。

2. 数据变更通知：当被监控的节点数据发生变化（如数据更新、节点删除等），所有注册了该节点watcher的客户端都会收到通知。

3. 一次性触发：watcher是一次性的，即一旦触发，它就会被移除。客户端需要重新注册watcher来继续接收通知。

4. 轻量级：watcher机制是轻量级的，它不会对Zookeeper的性能产生显著影响。

5. 状态保持：客户端可以通过watcher来保持对Zookeeper中数据状态的感知，这对于分布式系统的同步和协调非常重要。

6. 客户端库支持：大多数Zookeeper客户端库都提供了对watcher机制的支持，使得开发者可以很容易地在自己的应用中实现这一机制。

7. 类型多样：Zookeeper支持多种类型的事件，例如节点创建、节点删除、节点数据变更等，客户端可以根据自己的需要注册不同类型的watcher。

8. 顺序性保证：Zookeeper保证客户端会按照事件的顺序接收到通知，这对于保持数据的一致性至关重要。

通过watcher机制，Zookeeper能够为分布式应用提供一种有效的方式来实现数据的同步和状态的监控，这对于构建可靠的分布式系统至关重要。

4. Zookeeper集群不得少于几台服务器，集群规则是什么？

ZooKeeper集群的最小规模和集群规则主要受故障容忍能力的影响。以下是一些基本规则：

1. 最小规模：ZooKeeper集群至少需要3台服务器。这是最小推荐的配置，因为它允许集群在一台服务器故障时仍然保持运行（即容忍一台服务器的故障）。

2. 奇数规则：ZooKeeper集群的服务器数量应该是奇数。这是因为在领导者选举过程中，奇数个投票者（服务器）可以确保在大多数情况下（即超过一半）达成共识。

3. 故障容忍：集群可以容忍的最大故障服务器数量是 (n/2) - 1，其中 n 是集群中服务器的总数。例如，一个5台服务器的集群可以容忍2台服务器的故障。

4. 领导者选举：在ZooKeeper集群中，一台服务器会被选举为领导者（Leader），负责处理客户端的读写请求。其他服务器作为追随者（Follower）或观察者（Observer）。

5. 写入保证：ZooKeeper保证写入操作在被提交前，必须被集群中的大多数服务器（即超过一半的服务器）确认。

6. 读操作：读操作可以由领导者或追随者处理，但是写操作必须通过领导者。

7. 观察者：从3.3.0版本开始，ZooKeeper引入了观察者（Observer）角色，观察者不参与领导者选举的投票过程，但它们可以接收数据的副本，帮助分担客户端的读取压力。

8. 网络分区：ZooKeeper使用Zab协议来处理网络分区问题，确保在网络分区发生时，集群能够继续提供服务（尽管可能只在一个分区中）。

9. 数据一致性：ZooKeeper保证了顺序一致性、原子性和可靠性，这意味着客户端将按照操作的顺序看到更新，并且所有的更新都是原子的，一旦提交就不会丢失。

10. 集群配置：集群的配置通常在一个配置文件中定义，包括每台服务器的ID和它们在集群中的角色。

综上所述，ZooKeeper集群的最小规模是3台服务器，并且遵循奇数规则和故障容忍规则来确保高可用性和一致性。

5. Zookeeper有哪几种几种部署模式？

Zookeeper有三种主要的部署模式：

1. 单机模式（Standalone模式）：这是最基本的部署方式，仅运行一个Zookeeper服务实例。适用于开发和测试环境，不适用于生产环境，因为单机模式没有提供高可用性[¹][⁶][⁸][¹⁰]。

2. 伪集群模式：在一台机器上运行多个Zookeeper服务实例，每个实例使用不同的端口。虽然这可以提供一定程度的冗余，但并不是真正的集群，因为所有实例都运行在同一个物理机器上，如果机器出现故障，整个Zookeeper服务将不可用[¹][³][⁶][⁸]。

3. 集群模式：在多台机器上运行多个Zookeeper服务实例，形成一个真正的集群。这是生产环境中推荐的方式，因为它提供了高可用性和故障转移能力。集群中的Zookeeper实例会通过Zab协议（Zookeeper Atomic Broadcast）来保持数据的一致性[¹][²][³][⁶][⁸][¹⁰]。

集群模式是Zookeeper部署中最为健壮和推荐的方式，因为它可以提供真正的高可用性，并且能够在集群中的某些机器发生故障时继续提供服务。

6. 请阐述Zookeeper是如何选取主leader的？

ZooKeeper集群在启动时或领导者崩溃后需要选举一个新的领导者（Leader）。以下是ZooKeeper选举领导者的步骤：

1. 初始化阶段：每个服务器（称为Follower或Candidate）开始时都处于初始化阶段。在这个阶段，服务器尝试与集群中的其他服务器建立连接。

2. 投票：每个服务器会生成一个投票。投票包含两个主要信息：服务器的ID和它所知的最新的事务ID（zxid）。事务ID是ZooKeeper中用于标识操作的全局单调递增的数字。

3. 广播投票：服务器将自己的投票广播给集群中的其他所有服务器。

4. 收集投票：每个服务器收集来自其他服务器的投票。服务器会根据以下规则处理收集到的投票：

   • 如果收到的投票是自己的，那么它会继续等待更多的投票。
   • 如果收到的投票来自具有更高服务器ID的服务器，那么当前服务器会接受这个投票，并更新自己的投票信息。
   • 如果收到的投票来自具有相同服务器ID的服务器，但是具有更高的事务ID，那么当前服务器也会接受这个投票，并更新自己的投票信息。

5. 确定领导者：一旦服务器收到来自集群中大多数服务器的投票，它将检查这些投票：

   • 如果大多数投票都是投给自己的，那么当前服务器将成为新的领导者。
   • 如果大多数投票是投给其他服务器的，那么当前服务器将接受这个服务器作为领导者。

6. 领导者确认：一旦确定了领导者，领导者会向所有服务器发送一个通知，告知它们自己的领导者地位。

7. 集群同步：新的领导者会与集群中的其他服务器进行同步，确保所有服务器的状态与领导者保持一致。

8. 客户端通知：一旦领导者被选举出来，并且集群状态同步完成，领导者将开始接受客户端的请求。

ZooKeeper的领导者选举过程是动态的，能够快速响应领导者的变更，并确保集群的高可用性和一致性。选举过程依赖于服务器ID和事务ID来决定领导者，这样可以确保具有最新数据的服务器有更大的机会成为领导者。

7. Zookeeper是如何保证事务的顺序一致性的？

ZooKeeper保证事务的顺序一致性主要依赖于以下几个关键机制：

1. 全局唯一序列号：ZooKeeper为每个事务请求分配一个全局唯一的序列号，称为ZXID（ZooKeeper Transaction ID）。这个序列号是递增的，确保了事务的全局顺序性。

2. 原子广播协议（Zab）：ZooKeeper使用Zab协议来确保集群中的数据一致性。Zab协议分为两个阶段：领导者选举阶段和原子广播阶段。在领导者选举阶段，集群中的服务器会选举出一个领导者（Leader）。一旦Leader被选举出来，它将负责处理所有的事务请求。在原子广播阶段，Leader将事务请求广播给所有的跟随者（Follower），并确保所有的Follower按照相同的顺序提交事务。

3. Leader负责提交事务：在ZooKeeper集群中，只有Leader节点负责处理客户端的事务请求。Leader接收到事务请求后，会生成一个提案（Proposal），并将其发送给所有的Follower。Follower接收到提案后，会对其进行投票，如果超过半数的Follower投票同意，Leader就会提交这个事务，并通知所有的Follower更新状态。

4. 状态同步：Follower会定期与Leader进行状态同步，确保自己的状态与Leader保持一致。这有助于在网络分区或其他异常情况下，Follower能够快速地恢复到与Leader一致的状态。

5. 持久化存储：ZooKeeper将事务日志持久化存储在磁盘上，这样即使系统发生故障，也能够通过事务日志恢复到一致的状态。

6. 会话管理：ZooKeeper为每个客户端会话分配一个唯一的会话ID，并保证会话ID的顺序一致性。客户端的请求都是在会话的上下文中进行的，ZooKeeper会根据会话ID来处理客户端的请求。

通过这些机制，ZooKeeper能够确保即使在分布式环境中，事务也能够保持顺序一致性，从而为客户端提供可靠的协调服务。