本期将带领大家入门学习 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 内容。
可扫码关注