Zookeeper-03-ZK的ZAB协议和工作原理

最新推荐文章于 2024-05-16 22:54:28 发布

苍煜

最新推荐文章于 2024-05-16 22:54:28 发布

阅读量762

点赞数 1

分类专栏： # zookeeper 文章标签： zookeeper 分布式 java

本文链接：https://blog.csdn.net/qq_41694906/article/details/124622670

版权

zookeeper 专栏收录该内容

6 篇文章 0 订阅

订阅专栏

文章目录

1：Zookeeper基本概念
2：Zookerper算法
- 1：paxos算法
- 2：ZAB协议
3：Zookeeper工作原理
4：Zookeeper的watch监测功能

1：Zookeeper基本概念

1：Zookeeper是什么

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，它包含一个简单的原语集，分布式应用程序可以基于它实现同步服务，配置维护和命名服务等。Zookeeper是hadoop的一个子项目，其发展历程无需赘述。在分布式应用中，由于工程师不能很好地使用锁机制，以及基于消息的协调机制不适合在某些应用中使用，因此需要有一种可靠的、可扩展的、分布式的、可配置的协调机制来统一系统的状态

2：Zookeeper能做什么

最终一致性：client不论连接到哪个Server，展示给它都是同一个视图，这是zookeeper最重要的性能。
可靠性：具有简单、健壮、良好的性能，如果消息m被到一台服务器接受，那么它将被所有的服务器接受。
实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。但由于网络延时等原因，Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。
等待无关（wait-free）：慢的或者失效的client不得干预快速的client的请求，使得每个client都能有效的等待。
原子性：更新只能成功或者失败，没有中间状态。
顺序性：包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有Server上消息a都将在消息b前被发布；偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面。

3：Zookeeper角色

在这里插入图片描述
也就是说在系统中只有leader能写，follower只可以读不能写，但是follower可以通过选举产生新的leader（前提是旧的leader挂了）

2：Zookerper算法

Zookeeper 作为一个集群提供一致的数据服务，要实现数据可靠可用一致性，那么就有了几个问题：
1：leader挂了怎么办？
2：follower挂了好几个怎么办？
3：集群获得的数据不一致怎么办？
答：
1：leader挂了，由follower选举新的leader（过半同意）
2：follower挂了，只要剩下过半的服务器就能选举新的leader，如果没有过半服务器，整个服务挂掉
3：在集群数据同步过程中可能出现数据不一致情况，但是会实现最终一致性。也可以由客户端调用sync()来使数据强一致性；
那么要了解怎么解决的我们需要详细了解zk的算法；

1：paxos算法

Paxos 算法通过投票来对写操作进行全局编号，同一时刻，只有一个写操作被批准，同时并发的写操作要去争取选票，只有获得过半数选票的写操作才会被批准（所以永远只会有一个写操作得到批准），其他的写操作竞争失败只好再发起一轮投票，就这样，所有写操作都被严格编号排序，编号严格递增。当一个节点接受了一个编号为100的写操作，之后又接受到编号为99的写操作（因为网络延迟等很多不可预见原因），它马上能意识到自己数据不一致了，自动停止对外服务并重启同步过程。任何一个节点挂掉都不会影响整个集群的数据一致性（总 2n+1 台，除非挂掉大于 n 台）。
推荐阅读这篇文章，以故事方式了解paxos算法https://www.douban.com/note/208430424/

2：ZAB协议

ZAB 协议全称：Zookeeper Atomic Broadcast（Zookeeper 原子广播协议）。

原子：成功、失败。没有中间状态（队列+2PC）
广播：分布式多借点的。全部知道！(过半)

Zookeeper 是一个为分布式应用提供高效且可靠的分布式协调服务。在解决分布式一致性方面，Zookeeper 并没有使用 Paxos ，而是采用了 ZAB 协议。

ZAB 协议定义：ZAB 协议是为分布式协调服务 Zookeeper 专门设计的一种支持崩溃恢复和原子广播协议。下面我们会重点讲这两个东西。

基于该协议，Zookeeper 实现了一种主备模式的系统架构来保持集群中各个副本之间数据一致性。具体如下图所示：
在这里插入图片描述
上图显示了 Zookeeper 如何处理集群中的数据。所有客户端写入数据都是写入到主进程（称为 Leader）中，然后，由 Leader 复制到备份进程（称为 Follower）中。从而保证数据一致性。从设计上看，和 Raft 类似。

那么复制过程又是如何的呢？复制过程类似 2PC，ZAB 只需要 Follower 有一半以上返回 Ack 信息就可以执行提交，大大减小了同步阻塞。也提高了可用性。

3：Zookeeper工作原理

1：Zookeeper工作原理概述

Zookeeper的核心是原子广播(ZAB下边讲)，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和 leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。

为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。ZXID 是一个 64 位的数字，
在这里插入图片描述

其中低 32 位可以看作是一个简单的递增的计数器，针对客户端的每一个事务请求，Leader 都会产生一个新的事务 Proposal 并对该计数器进行 + 1 操作。

而高 32 位则代表了 Leader 服务器上取出本地日志中最大事务 Proposal 的 ZXID，并从该 ZXID 中解析出对应的 epoch 值，然后再对这个值加一。

高 32 位代表了每代 Leader 的唯一性，低 32 代表了每代 Leader 中事务的唯一性。同时，也能让 Follwer 通过高 32 位识别不同的 Leader。简化了数据恢复流程。

基于这样的策略：当 Follower 链接上 Leader 之后，Leader 服务器会根据自己服务器上最后被提交的 ZXID 和 Follower 上的 ZXID 进行比对，比对结果要么回滚，要么和 Leader 同步。

每个Server在工作过程中有三种状态：

LOOKING：当前Server不知道leader是谁，正在搜寻
LEADING：当前Server即为选举出来的leader
FOLLOWING：leader已经选举出来，当前Server与之同步

2：选主leader流程

zk选主分为两种，一种是刚启动时，一种是旧的leader奔溃之后；

当leader崩溃或者leader失去大多数的follower，这时候zk进入恢复模式，恢复模式需要重新选举出一个新的leader，让所有的 Server都恢复到一个正确的状态。Zk的选举算法有两种：一种是基于basic paxos实现的，另外一种是基于fast paxos算法实现的。系统默认的选举算法为fast paxos。先介绍basic paxos流程：

1 .选举线程由当前Server发起选举的线程担任，其主要功能是对投票结果进行统计，并选出推荐的Server；
2 .选举线程首先向所有Server发起一次询问(包括自己)；
3 .选举线程收到回复后，验证是否是自己发起的询问(验证zxid是否一致)，然后获取对方的id(myid)，并存储到当前询问对象列表中，最后获取对方提议的leader相关信息( id,zxid)，并将这些信息存储到当次选举的投票记录表中；
4. 收到所有Server回复以后，就计算出zxid最大的那个Server，并将这个Server相关信息设置成下一次要投票的Server；
5. 线程将当前zxid最大的Server设置为当前Server要推荐的Leader，如果此时获胜的Server获得n/2 + 1的Server票数，设置当前推荐的leader为获胜的Server，将根据获胜的Server相关信息设置自己的状态，否则，继续这个过程，直到leader被选举出来。

通过流程分析我们可以得出：要使Leader获得多数Server的支持，则Server总数必须是奇数2n+1，且存活的Server的数目不得少于n+1.

每个Server启动后都会重复以上流程。在恢复模式下，如果是刚从崩溃状态恢复的或者刚启动的server还会从磁盘快照中恢复数据和会话信息，zk会记录事务日志并定期进行快照，方便在恢复时进行状态恢复。选主的具体流程图如下所示：
在这里插入图片描述
fast paxos流程是在选举过程中，某Server首先向所有Server提议自己要成为leader，当其它Server收到提议以后，解决epoch和 zxid的冲突，并接受对方的提议，然后向对方发送接受提议完成的消息，重复这个流程，最后一定能选举出Leader。其流程图如下所示：
在这里插入图片描述

总结：
ZK选举过程：1,3888造成两两通信！
2，只要任何人投票，都会触发那个准leader发起自己的投票
3，推选制：先比较zxid，如果zxid相同，再比较myid,最终选出新的leader

3：数据同步流程

选完leader以后，zk就进入状态同步过程。

    1. leader等待server连接；

    2 .Follower连接leader，将最大的zxid发送给leader；

    3 .Leader根据follower的zxid确定同步点；

    4 .完成同步后通知follower 已经成为uptodate状态；

    5 .Follower收到uptodate消息后，又可以重新接受client的请求进行服务了。

总结：同步流程（广播）类似一个二阶段提交过程。对于客户端发送的写请求，全部由 Leader 接收，Leader 将请求封装成一个事务 Proposal，将其发送给所有 Follwer ，然后，根据所有 Follwer 的反馈，如果超过半数成功响应，则执行 commit 操作（先提交自己，再发送 commit 给所有 Follwer）。

4：工作流程

1：Leader工作流程

Leader主要有三个功能：

    1 .恢复数据；

    2 .维持与Learner的心跳，接收Learner请求并判断Learner的请求消息类型；

    3 .Learner的消息类型主要有PING消息、REQUEST消息、ACK消息、REVALIDATE消息，根据不同的消息类型，进行不同的处理。
   注： PING消息是指Learner的心跳信息；REQUEST消息是Follower发送的提议信息，包括写请求及同步请求；ACK消息是 Follower的对提议的回复，超过半数的Follower通过，则commit该提议；REVALIDATE消息是用来延长SESSION有效时间。

leader的工作流程简图如下所示，在实际实现中，流程要比下图复杂得多，启动了三个线程来实现功能。
在这里插入图片描述

2：Follower工作流程

Follower主要有四个功能：

    1. 向Leader发送请求（PING消息、REQUEST消息、ACK消息、REVALIDATE消息）；

    2 .接收Leader消息并进行处理；

    3 .接收Client的请求，如果为写请求，发送给Leader进行投票；

    4 .返回Client结果。

Follower的消息循环处理如下几种来自Leader的消息：

    1 .PING消息： 心跳消息；

    2 .PROPOSAL消息：Leader发起的提案，要求Follower投票；

    3 .COMMIT消息：服务器端最新一次提案的信息；

    4 .UPTODATE消息：表明同步完成；

    5 .REVALIDATE消息：根据Leader的REVALIDATE结果，关闭待revalidate的session还是允许其接受消息；

    6 .SYNC消息：返回SYNC结果到客户端，这个消息最初由客户端发起，用来强制得到最新的更新。

Follower的工作流程简图如下所示，在实际实现中，Follower是通过5个线程来实现功能的。
在这里插入图片描述

5:总结zk工作流程

在这里插入图片描述
如上图所示：
1：当客户端发起一个更新请求时，请求打到leader上
2：leader通过检查Zxid确认是新的指令
3：ledder将更新请求下发到所有的follower上
4：follower将更新请求记录在自己的日志上，然后返回ok
5：leader获得过半的follower的ok返回，就会更新此指令，并告诉客户端，然后广播给所有的follower
6：所有的follower收到更新指令，更新自己的数值。

4：Zookeeper的watch监测功能

在这里插入图片描述
zk集群可以通过某个客户端的session创建的临时节点，对该节点进行监控，一旦该临时节点没了，代表此客户端失去连接。此时就可以通过监控的回调函数（callback）执行一定的任务，比如通知其他客户端。
这样的监控比客户端A通过心跳监控客户端B更叫高效，毕竟通过心跳监测是定时监测，而watch是实时通知；