关于你对 Zookeeper 的理解

看看普通人和高手是如何回答这个问题的？

普通人

Zookeeper 是一种开放源码的分布式应用程序协调服务

是一个分布式的小文件存储系统

一般对开发者屏蔽分布式应用开发过过程种的底层细节

用来解决分布式集群中应用系统的一致性问题

高手

对于 Zookeeper 的理解，我觉得可以从分布式系统中的三种典型应用场景说起：

第一种：集群管理

在多个节点组成的集群中，为了保证集群的 HA 特性，每个节点都会冗余一份据副本。这种情况下需要保证客户端访问集群中的任意一个节点都是最新的数据。

一个 Zookeeper 集群通常由一组机器组成，一般3~5台集群就可以组成一个 Zookeeper 集群。集群拓扑图基本如下：

Zookeeper 集群中每一个节点都会在内存中维护当前的节点状态，并且彼此之间保持着通信。这里说明一点，只要集群中存在过半的节点正常工作，整个集群就能够对外提供服务。

如上图，在 Zookeeper 集群中，有 Leader、Follower 和 Observer 三种类型的角色。

Leader

Leader 节点整个 Zookeeper 集群工作机制中的核心，主要工作是处理客户端的读写请求，及集群内部各服务的调度。注意只有 leader 能够处理写请求。

Follower

处理客户端的读请求，将写请求转发给 leader。参与 leader 选举投票等。

Observer

这是自 Zookeeper 3.3.0 版本引入的一个新的角色，主要是为了解决大规模 Server 场景下因 leader 选举投票成本增加导致写性能下降的问题。Observer 的工作原理和 follower 基本一致。处理客户端的读请求，将写请求转发给leader。和 follower 唯一的区别在于，Observer 不参与任何形式的选举，包括 leader 选举。

一般而言，中小型规模的 Zookeeper 集群中只包含 leader 和 follower 两个角色，这容易让我们忽略 observer 角色的存在。配置一个节点为 observer 也很简单，只需如下两步：

# 在observer节点的配置文件中添加如下配置
peerType=observer

# 在每个节点的配置文件中，给observer节点添加:observer标识
# 例如：
server.1:localhost:2181:3181:observer

至此，相信你对 Zookeeper 的集群架构与相关角色有了一定认识。

第二种：分布式锁

如何保证跨进程的共享资源的并发安全性，对于分布式系统来说也是一个比较大的挑战，而为了达到这样一个目的，必须要使用跨进程的锁也就是分布式锁来实现。

不同节点上的服务，可能需要同时访问一个资源，这时可能需要一把分布式锁。使用 Zookeeper 实现分布式锁主要基于以下特性：

• ZooKeeper 的强一致性，保证只有一个客户端能够创建锁成功。
• 锁的独占性，创建 ZNode 成功的客户端才能得到锁，其他客户端只能等待，当客户端用完释放锁时，其他客户端再次尝试创建 ZNode，获取分布式锁。

第三种： Master 选举

在多个节点组成的集群中，为了降低集群数据同步的复杂度，一般会存在 Master和 Slave 两种角色的节点，Master 负责事务和非事务请求处理，Slave 负责非事务请求处理。但是在分布式系统中如何确定某个节点是 Master 还是 Slave，也成了一个难度不小的挑战。

基于这三类常见场景的需求，所以产生了 Zookeeper 这样一个中间件。它是一个分布式开源协调组件，简单来说，就是类似于一个裁判员的角色，专门负责协调和解决分布式系统中的各类问题。

Master 选举是一个分布式系统中非常常见的场景，这里是利用 Zookeeper 的强一致性，保证只有一个客户端能够创建节点成功。

比如，针对上述描述的问题，Zookeeper 都可以解决。

\1. 集群管理

Zookeeper 提供了 CP 的模型，来保证集群中的每个节点的数据一致性，当然Zk 本身的集群并不是 CP 模型，而是顺序一致性模型，如果要保证 CP 特性，需要调用 sync 同步方法。

\2. 分布式锁

Zookeeper 提供了多种不同的节点类型，如持久化节点、临时节点、有序节点、容器节点等，其中对于分布式锁这个场景来说，Zookeeper 可以利用有序节点的特性来实现。除此之外，还可以利用同一级节点的唯一性特性来实现分布式锁。

\3. Master 选举

Zookeeper 可以利用持久化节点来存储和管理其他集群节点的信息，从而进行Master 选举机制。或者还可以利用集群中的有序节点特性，来实现 Master 选举。

目前主流的 Kafka、Hbase、Hadoop 都是通过 Zookeeper 来实现集群节点的主从选举。

总的来说，Zookeeper 就是经典的分布式数据一致性解决方案，致力于为分布式应用提供高性能、高可用，并且具有严格顺序访问控制能力的分布式协调服务。 它底层通过基于 Paxos 算法演化而来的 ZAB 协议实现。

Zookeeper 数据模型

Zookeeper 的数据模型是一棵类似 Unix 文件系统的 ZNode Tree 即 ZNode 树，但是没有引入传统文件系统的目录或者文件等概念，而是使用了称为 “数据节点” 的概念，术语叫做 ZNode。ZNode 是 Zookeeper 存储数据的最小单元，每个 ZNode 可以保存数据，也可以挂载子节点，其中根节点是 /。示意图如下：

使用过 Zookeeper 的同学应该都知道，Zookeeper 主要提供了两个核心功能：

• 管理（存储、读取）客户端提交的数据；
• 为客户端提供数据节点的监听服务；

这里就涉及到 Zookeeper 的两个重要特性，就是它的 ZNode 模型与 Watcher 机制。

ZNode 模型

前面讲到 Zookeeper 是由数据节点 ZNode 构成的，Zookeeper 中的每个数据节点都是有生命周期的，其生命周期的长短取决于 ZNode 的节点类型。ZNode 根据其生命周期和特点可分为 4 类。

分别是：

• 持久性节点（PERSISTENT）：客户端与 Zookeeper 断开会话后，该节点依旧存在，直到执行删除操作才会清除节点。
• 持久性顺序节点（PERSISTENT_SEQUENTIAL）：另一种持久节点，Zookeeper 会给该节点名称加上一个数字后缀，进行顺序编号。
• 临时节点（EPHEMERAL）：节点的生命周期和客户端的会话绑定在一起，客户端与 Zookeeper 断开会话后，该节点就会被自动删除。各个场景中很多都是利用 Zookeeper 临时节点这个特性的。
• 临时顺序节点（EPHEMERAL_SEQUENTIAL）：概念和上面类似，Zookeeper 也会给该节点进行顺序编号。

前面提及了 ZNode 是存储数据的最小单元，除了存储用户数据外，ZNode 还有以下特点：

• 包含 ZNode 修改/访问的时间、事务id(zxid)，ACL 权限、版本等状态信息；
• 所有的事务请求在 ZNode 端都是顺序和原子性的；
• 数据主要存储在内存中，磁盘中保存事务日志、快照数据等；

Watcher 机制

Watcher 机制也称监听机制，它是 Zookeeper 的关键特性，是通过 ZooKeeper 实现分布式发布/订阅、分布式锁、集群管理等功能的基础。

如上图所示，Zookeeper 允许客户端向服务端注册一个 Watcher 监听器，当服务端的一些指定事件触发了该监听，比如节点创建、删除，节点数据变更等事件，Zookeeper 就会向注册了监听器的客户端发送相应的事件通知。

以上就是我对于 Zookeeper 的理解。