ZooKeeper 学习必看系列，强烈推荐

本期将带领大家入门学习 ZooKeeper 系列的内容，力求通俗易懂，图文并茂。

ZooKeeper 系列文章将以以下内容为主线讲解，包括 ZooKeeper 中的角色、ZAB协议、数据模型、选举机制、监听器原理以及应用场景等。会对相关的面试题或开发中常见内容，进行重点讲解。

1. 什么是ZooKeeper

ZooKeeper 是一个分布式协调服务，其设计的初衷是为分布式软件提供一致性服务。其本质上，就是文件系统+通知机制。

ZooKeeper 提供了一个类似 Linux 文件系统的树形结构，ZooKeeper 的每个节点既可以是目录也可以是数据，并且 ZooKeeper 还提供了对每个节点的监控与通知机制。

2. ZooKeeper 的工作机制

ZooKeeper 采用的是主从模式，有主节点和从节点。从设计模式的角度，它是一个基于观察者模式设计的分布式服务管理框架，负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，ZooKeeper 就将负责通知已经注册的那些观察者做出相应的反应。

3. ZooKeeper 的角色及其关系

ZooKeeper 中的角色包括 Leader、Follower、Observer。Leader 是集群主节点，主要负责管理集群状态和接收用户的写请求；Follower 是从节点，主要负责集群选举投票和接收用户的读请求；Observer 的功能与 Follower 类似，只是没有投票权，主要用于分担 Follower 的读请求，降低集群的负载。

a. Leader

一个运行中的 Zookeeper 集群只有一个 Leader 服务，Leader 服务主要包括以下两个指责：

• 负责集群数据的写操作。所有写操作必须要 Leader 完成之后，才可以将写操作广播到其他 Follower，并且只有超过半数节点（不包括 Observer）写入成功后，这些写请求才算写成功；
• 发起并维护各个 Follower 以及 Observer 之间的心跳，以监控集群的运行状态。

b. Follower
一个 Zookeeper 集群可以有多个 Follower，Follower通过心跳与 Leader 保持连接。Follower 服务主要有以下两个指责：

• 负责集群数据的读操作。Follower 在接受到一个客户端请求之后，会先判断该请求是读请求还是写请求，若为读请求，则 Follower 从本地节点上读取数据并返回给客户端；若为写请求，则 Follower 会将写请求转发给 Leader 来处理。
• 参与集群中 Leader 的选举。当 Leader 失效之后，Follower 需要在集群选举时进行投票；（后续会详细讲解选举机制）

c. Observer

一个 Zookeeper 集群可以有多个 Observer，Observer 的主要职责是负责集群数据的读操作，其功能同以上介绍的 Follower 的功能类似，主要的差别就是 Observer 没有投票权。

面试题：Follower 已经具备了 Observer 的所有功能，为什么还要设计 Observer 角色 ？

这是因为 ZooKeeper 集群在运行过程中要支持更多的客户端并发的操作，就需要增加更多的服务实例，而过多的服务实例会使得集群的投票阶段变得复杂，选举时间过长不利于集群故障的快速恢复。
因此，ZooKeeper 引入了 Observer 角色，Observer 不参与投票，只负责接收客户端来的读请求，以及将写请求转发给 Leader 。加入更多的 Observer 节点，不仅提高了 ZooKeeper 集群的吞吐量，保障了系统的稳定性。

---

以上是本期分享，如有帮助请 点赞+关注+收藏 支持下哦～
下期继续讲解 ZooKeeper 内容。

可扫码关注