吃透Zookeeper五大核心内容后，你的问题完全可以一键消除

2401_84049061

于 2024-04-20 11:15:48 发布

阅读量699

点赞数 30

分类专栏：程序员文章标签： zookeeper 分布式云原生

本文链接：https://blog.csdn.net/2401_84049061/article/details/137994133

版权

程序员专栏收录该内容

433 篇文章 1 订阅

订阅专栏

命名服务是指通过指定的名字来获取资源或者服务的地址，利用 zk 创建一个全局唯一的路径，这个路径就可以作为一个名字，指向集群中的集群，提供的服务的地址，或者一个远程的对象等等。

5. 分布式协调/通知

对于系统调度来说，用户更改zk某个节点的value， ZooKeeper会将这些变化发送给注册了这个节点的 watcher 的所有客户端，进行通知。
对于执行情况汇报来说，每个工作进程都在目录下创建一个携带工作进度的临时节点，那么汇总的进程可以监控目录子节点的变化获得工作进度的实时的全局情况。

6. 集群管理

大数据体系下的大部分集群服务好像都通过ZooKeeper管理的，其实管理的时候主要关注的就是机器的动态上下线跟Leader选举。

动态上下线：

比如在zookeeper服务器端有一个znode叫 /Configuration，那么集群中每一个机器启动的时候都去这个节点下创建一个EPHEMERAL类型的节点，比如server1 创建 /Configuration/Server1，server2创建**/Configuration /Server1**，然后Server1和Server2都watch /Configuration 这个父节点，那么也就是这个父节点下数据或者子节点变化都会通知到该节点进行watch的客户端。

Leader选举：

利用ZooKeeper的强一致性，能够保证在分布式高并发情况下节点创建的全局唯一性，即：同时有多个客户端请求创建 /Master 节点，最终一定只有一个客户端请求能够创建成功。利用这个特性，就能很轻易的在分布式环境中进行集群选举了。
就是动态Master选举。这就要用到 EPHEMERAL_SEQUENTIAL类型节点的特性了，这样每个节点会自动被编号。允许所有请求都能够创建成功，但是得有个创建顺序，每次选取序列号最小的那个机器作为Master 。

3 Leader选举

ZooKeeper集群节点个数一定是奇数个，一般3个或者5个就OK。为避免集群群龙无首，一定要选个大哥出来当Leader。这是个高频考点。

3.1 预备知识

3.1.1. 节点四种状态。

LOOKING：寻找 Leader 状态。当服务器处于该状态时会认为当前集群中没有 Leader，因此需要进入 Leader 选举状态。
FOLLOWING：跟随者状态。处理客户端的非事务请求，转发事务请求给 Leader 服务器，参与事务请求 Proposal(提议) 的投票，参与 Leader 选举投票。
LEADING：领导者状态。事务请求的唯一调度和处理者，保证集群事务处理的顺序性，集群内部个服务器的调度者(管理follower,数据同步)。
OBSERVING：观察者状态。3.0 版本以后引入的一个服务器角色，在不影响集群事务处理能力的基础上提升集群的非事务处理能力，处理客户端的非事务请求，转发事务请求给 Leader 服务器，不参与任何形式的投票。

3.1.2 服务器ID

既Server id，一般在搭建ZK集群时会在myid文件中给每个节点搞个唯一编号，编号越大在Leader选择算法中的权重越大，比如初始化启动时就是根据服务器ID进行比较。

3.1.3 ZXID

ZooKeeper 采用全局递增的事务 Id 来标识，所有 proposal(提议)在被提出的时候加上了ZooKeeper Transaction Id ，zxid是64位的Long类型，这是保证事务的顺序一致性的关键。zxid中高32位表示纪元epoch，低32位表示事务标识xid。你可以认为zxid越大说明存储数据越新。

每个leader都会具有不同的epoch值，表示一个纪元/朝代，用来标识 leader 周期。每个新的选举开启时都会生成一个新的epoch，新的leader产生的话epoch会自增，会将该值更新到所有的zkServer的zxid和epoch，
xid是一个依次递增的事务编号。数值越大说明数据越新，所有 proposal（提议）在被提出的时候加上了zxid，然后会依据数据库的两阶段过程，首先会向其他的 server 发出事务执行请求，如果超过半数的机器都能执行并且能够成功，那么就会开始执行。

3.2 Leader选举

Leader的选举一般分为启动时选举跟Leader挂掉后的运行时选举。

3.2.1 启动时Leader选举

我们以上面的5台机器为例，只有超过半数以上，即最少启动3台服务器，集群才能正常工作。

服务器1启动，发起一次选举。

服务器1投自己一票。此时服务器1票数一票，不够半数以上（3票），选举无法完成，服务器1状态保持为LOOKING。

服务器2启动，再发起一次选举。

服务器1和2分别投自己一票，此时服务器1发现服务器2的id比自己大，更改选票投给服务器2。此时服务器1票数0票，服务器2票数2票，不够半数以上（3票），选举无法完成。服务器1，2状态保持LOOKING。

服务器3启动，发起一次选举。

与上面过程一样，服务器1和2先投自己一票，然后因为服务器3id最大，两者更改选票投给为服务器3。此次投票结果：服务器1为0票，服务器2为0票，服务器3为3票。此时服务器3的票数已经超过半数（3票），服务器3当选Leader。服务器1，2更改状态为FOLLOWING，服务器3更改状态为LEADING；

服务器4启动，发起一次选举。

此时服务器1、2、3已经不是LOOKING状态，不会更改选票信息，交换选票信息结果。服务器3为3票，服务器4为1票。此时服务器4服从多数，更改选票信息为服务器3，服务器4并更改状态为FOLLOWING。

服务器5启动，发起一次选举

同4一样投票给3，此时服务器3一共5票，服务器5为0票。服务器5并更改状态为FOLLOWING；

最终

Leader是服务器3，状态为LEADING。其余服务器是Follower，状态为FOLLOWING。

3.2.2 运行时Leader选举

运行时候如果Master节点崩溃了会走恢复模式，新Leader选出前会暂停对外服务，大致可以分为四个阶段 选举、发现、同步、广播。

每个Server会发出一个投票，第一次都是投自己，其中投票信息 = (myid，ZXID)
收集来自各个服务器的投票
处理投票并重新投票，处理逻辑：优先比较ZXID，然后比较myid。
统计投票，只要超过半数的机器接收到同样的投票信息，就可以确定leader，注意epoch的增加跟同步。
改变服务器状态Looking变为Following或Leading。
当 Follower 链接上 Leader 之后，Leader 服务器会根据自己服务器上最后被提交的 ZXID 和 Follower 上的 ZXID 进行比对，比对结果要么回滚，要么和 Leader 同步，保证集群中各个节点的事务一致。
集群恢复到广播模式，开始接受客户端的写请求。

3.3 脑裂

脑裂问题是集群部署必须考虑的一点，比如在Hadoop跟Spark集群中。而ZAB为解决脑裂问题，要求集群内的节点数量为2N+1。当网络分裂后，始终有一个集群的节点数量过半数，而另一个节点数量小于N+1, 因为选举Leader需要过半数的节点同意，所以我们可以得出如下结论：

有了过半机制，对于一个Zookeeper集群，要么没有Leader，要没只有1个Leader，这样就避免了脑裂问题

4 一致性协议之 ZAB

建议先看下浅谈大数据中的2PC、3PC、Paxos、Raft、ZAB ，不然可能看的吃力。

4.1 ZAB 协议介绍

ZAB (Zookeeper Atomic Broadcast 原子广播协议) 协议是为分布式协调服务ZooKeeper专门设计的一种支持崩溃恢复的一致性协议。基于该协议，ZooKeeper 实现了一种主从模式的系统架构来保持集群中各个副本之间的数据一致性。

分布式系统中leader负责外部客户端的写请求。follower服务器负责读跟同步。这时需要解决俩问题。

Leader 服务器是如何把数据更新到所有的Follower的。
Leader 服务器突然间失效了，集群咋办？

因此ZAB协议为了解决上面两个问题而设计了两种工作模式，整个 Zookeeper 就是在这两个模式之间切换：

原子广播模式：把数据更新到所有的follower。
崩溃恢复模式：Leader发生崩溃时，如何恢复。

4.2 原子广播模式

你可以认为消息广播机制是简化版的 2PC协议，就是通过如下的机制保证事务的顺序一致性的。

leader从客户端收到一个写请求后生成一个新的事务并为这个事务生成一个唯一的ZXID，
leader将将带有 zxid 的消息作为一个提案(proposal)分发给所有 FIFO队列。
FIFO队列取出队头proposal给follower节点。
当 follower 接收到 proposal，先将 proposal 写到硬盘，写硬盘成功后再向 leader 回一个 ACK。
FIFO队列把ACK返回给Leader。
当leader收到超过一半以上的follower的ack消息，leader会进行commit请求，然后再给FIFO发送commit请求。
当follower收到commit请求时，会判断该事务的ZXID是不是比历史队列中的任何事务的ZXID都小，如果是则提交，如果不是则等待比它更小的事务的commit(保证顺序性)

4.3 崩溃恢复

消息广播过程中，Leader 崩溃了还能保证数据一致吗？当 Leader 崩溃会进入崩溃恢复模式。其实主要是对如下两种情况的处理。

Leader 在复制数据给所有 Follwer 之后崩溃，咋搞？
Leader 在收到 Ack 并提交了自己，同时发送了部分 commit 出去之后崩溃咋办？

针对此问题，ZAB 定义了 2 个原则：

ZAB 协议确保执行那些已经在 Leader 提交的事务最终会被所有服务器提交。
ZAB 协议确保丢弃那些只在 Leader 提出/复制，但没有提交的事务。

至于如何实现确保提交已经被 Leader 提交的事务，同时丢弃已经被跳过的事务呢？关键点就是依赖上面说到过的 ZXID了。

4.4 ZAB 特性

一致性保证

可靠提交(Reliable delivery) ：如果一个事务 A 被一个server提交(committed)了，那么它最终一定会被所有的server提交

全局有序(Total order)

假设有A、B两个事务，有一台server先执行A再执行B，那么可以保证所有server上A始终都被在B之前执行

因果有序(Causal order)

如果发送者在事务A提交之后再发送B,那么B必将在A之后执行

高可用性

只要大多数（法定数量）节点启动，系统就行正常运行

可恢复性

当节点下线后重启，它必须保证能恢复到当前正在执行的事务

4.5 ZAB 和 Paxos 对比

相同点：

两者都存在一个类似于 Leader 进程的角色，由其负责协调多个 Follower 进程的运行.
Leader 进程都会等待超过半数的 Follower 做出正确的反馈后，才会将一个提案进行提交.
ZAB 协议中，每个 Proposal 中都包含一个 epoch 值来代表当前的 Leader周期，Paxos 中名字为 Ballot

不同点：

ZAB 用来构建高可用的分布式数据主备系统（Zookeeper），Paxos 是用来构建分布式一致性状态机系统。

5 ZooKeeper 零散知识

5.1 常见指令

Zookeeper 有三种部署模式：

单机部署：一台机器上运行。
集群部署：多台机器运行。
伪集群部署：一台机器启动多个 Zookeeper 实例运行。

部署完毕后常见指令如下：

命令基本语法	功能描述
help	显示所有操作命令
ls path [watch]	显示所有操作命令
ls path [watch]	查看当前节点数据并能看到更新次数等数据
create	普通创建， -s 含有序列，
-e 临时（重启或者超时消失）
get path [watch]	获得节点的值
set	设置节点的具体值
stat	查看节点状态
delete	删除节点
rmr	递归删除节点

5.2 Zookeeper客户端

5.2.1. Zookeeper原生客户端

Zookeeper客户端是异步的哦！需要引入CountDownLatch 来确保连接好了再做下面操作。Zookeeper原生api是不支持迭代式的创建跟删除路径的，具有如下弊端。

会话的连接是异步的；必须用到回调函数。
Watch需要重复注册：看一次watch注册一次。
Session重连机制：有时session断开还需要重连接。
开发复杂性较高：开发相对来说比较琐碎。

5.2.2. ZkClient

开源的zk客户端，在原生API基础上封装，是一个更易于使用的zookeeper客户端，做了如下优化。

优化一、在session loss和session expire时自动创建新的ZooKeeper实例进行重连。优化二、将一次性watcher包装为持久watcher。

5.2.3. Curator

开源的zk客户端，在原生API基础上封装，apache顶级项目。是Netflix公司开源的一套Zookeeper客户端框架。了解过Zookeeper原生API都会清楚其复杂度。Curator帮助我们在其基础上进行封装、实现一些开发细节，包括接连重连、反复注册Watcher和NodeExistsException等。目前已经作为Apache的顶级项目出现，是最流行的Zookeeper客户端之一。