Zookeeper高可用原理及角色分析

高可用机制

一个 ZooKeeper 集群如果要对外提供可用的服务，那么集群中必须要有过半的机器正常工作并且彼此之间能够正常通信。

如果想搭建一个能够允许 N 台机器 down 掉的集群，那么就要部署一个由 2*N+1 台服务器构成的 ZooKeeper 集群。

所以部署3个节点，那么就得至少有2个节点可用则该集群才可用。4个节点同样还是要2个以上。

所以Zookeeper集群部署的节点（非Observer）数一般为奇数

高可用机制其实基于ZAB协议

1、Zookeeper的角色

zk提供了什么，简单的说，zookeeper=文件系统+通知机制

1、领导者（leader），负责进行投票的发起和决议，更新系统状态

2、学习者（learner），包括跟随者（follower）和观察者（observer），follower用于接受客户端请求并想客户端返回结果，在选主过程中参与投票

3、Observer可以接受客户端连接，将写请求转发给leader，但observer不参加投票过程，只同步leader的状态，observer的目的是为了扩展系统，提高读取速度

4、客户端（client），请求发起方 

 

 

1.2 设计目的

1.最终一致性：client不论连接到哪个Server，展示给它都是同一个视图，这是zookeeper最重要的性能。

2 .可靠性：具有简单、健壮、良好的性能，如果消息被到一台服务器接受，那么它将被所有的服务器接受。

3 .实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。但由于网络延时等原因，Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。

4 .等待无关（wait-free）：慢的或者失效的client不得干预快速的client的请求，使得每个client都能有效的等待。

5.原子性：更新只能成功或者失败，没有中间状态。

6 .顺序性：包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有Server上消息a都将在消息b前被发布；偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面

2、zookeeper存在类型

数据模型ZNode：

这个存储结构是一个树形结构，其上的每一个节点，我们称之为“znode”。如下如所示：

 

 

 

每一个znode默认能够存储1MB的数据（对于记录状态性质的数据来说，够了）

可以使用zkCli命令，登录到zookeeper上，并通过ls、create、delete、sync等命令操作这些znode节点

znode除了名称、数据以外，还有一套属性：zxid。这套zid与时间戳对应，记录zid不同的状态

znode结构:

zxid：时间戳，每次修改znode都会生成一个新的zxid，如果zxid1小于zxid2，那么zxid1肯定在zxid2之前发生

实现中zxid是一个64位的数字，它高32位是epoch用来标识 leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，标识当前属于那个leader的统治时期。低32位用于递增计数。

zxid保证消息有序

version：对节点每次修改的版本进行+1

data：每一个znode默认能存储1MB的数据，对data的修改，都会导致zxid和version的变化

tick：租约协议的具体实现，如果当前节点的“临时节点”，在tick时间周期内没有收到新的客户租约，则视为无效

 

Zookeeper维护一个类似文件系统的数据结构：

每个子目录项如 NameService 都被称作为 znode，和文件系统一样，我们能够自由的增加、删除znode，在一个znode下增加、删除子znode，唯一的不同在于znode是可以存储数据的。

有四种类型的znode：

1、PERSISTENT-持久化目录节点

客户端与zookeeper断开连接后，该节点依旧存在

2、 PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点

客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号

3、EPHEMERAL-临时目录节点

客户端与zookeeper断开连接后，该节点被删除

4、EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点

客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号

3、核心原理（ZAB协议）

Zookeeper的核心是原子广播（Zookeeper Atomic Broadcast），这个机制保证了各个Server之间的同步。实现这个机制的协议叫做ZAB协议。

Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。Zab借鉴了Paxos算法，但又不像Paxos那样，是一种通用的分布式一致性算法。它是特别为Zookeeper设计的支持崩溃恢复的原子广播协议。

崩溃恢复

一旦 Leader 服务器出现崩溃或者由于网络原因导致 Leader 服务器失去了与过半 Follower 的联系，那么就会进入崩溃恢复模式。

消息广播

1）在zookeeper集群中，数据副本的传递策略就是采用消息广播模式。zookeeper中农数据副本的同步方式与二段提交相似，但是却又不同。二段提交要求协调者必须等到所有的参与者全部反馈ACK确认消息后，再发送commit消息。要求所有的参与者要么全部成功，要么全部失败。二段提交会产生严重的阻塞问题。

2）Zab协议中 Leader 等待 Follower 的ACK反馈消息是指“只要半数以上的Follower成功反馈即可，不需要收到全部Follower反馈”

 

Zookeeper 客户端会随机的链接到 zookeeper 集群中的一个节点

如果是读请求，就直接从当前节点中读取数据；

如果是写请求，那么节点就会向 Leader 提交事务，Leader 接收到事务提交，会广播该事务，只要超过半数节点写入成功，该事务就会被提交。

当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。

为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。

所有的提议（proposal）都在被提出的时候加上了zxid。

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

looking：当前Server不知道leader是谁，正在搜寻 　　　　

leading：当前Server即为选举出来的leader 　　　　

following：leader已经选举出来，当前Server与之同步

Zab 协议的特性：
1）Zab 协议需要确保那些已经在 Leader 服务器上提交（Commit）的事务最终被所有的服务器提交。
2）Zab 协议需要确保丢弃那些只在 Leader 上被提出而没有被提交的事务。

Zab协议原理

Zab协议要求每个 Leader 都要经历三个阶段：发现，同步，广播。

发现：要求zookeeper集群必须选举出一个 Leader 进程，同时 Leader 会维护一个 Follower 可用客户端列表。将来客户端可以和这些 Follower节点进行通信。

同步：Leader 要负责将本身的数据与 Follower 完成同步，做到多副本存储。这样也是提现了CAP中的高可用和分区容错。Follower将队列中未处理完的请求消费完成后，写入本地事务日志中。

广播：Leader 可以接受客户端新的事务Proposal请求，将新的Proposal请求广播给所有的 Follower。

 

4、选主流程

当leader崩溃或者leader失去大多数的follower，这时候zk进入恢复模式，恢复模式需要重新选举出一个新的leader，让所有的Server都恢复到一个正确的状态。

Zk的选举算法有两种：一种是基于basic paxos实现的，另外一种是基于fast paxos算法实现的。系统默认的选举算法为fast paxos。

先介绍basic paxos流程：

选举线程由当前Server发起选举的线程担任，其主要功能是对投票结果进行统计，并选出推荐的Server；

选举线程首先向所有Server发起一次询问(包括自己)；

选举线程收到回复后，验证是否是自己发起的询问(验证zxid是否一致)，然后获取对方的id(myid)，并存储到当前询问对象列表中，最后获取对方提议的leader相关信息(id,zxid)，并将这些信息存储到当次选举的投票记录表中；

收到所有Server回复以后，就计算出zxid最大的那个Server，并将这个Server相关信息设置成下一次要投票的Server；

线程将当前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。其流程图如下所示：

 

 

5、同步流程

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

leader等待server连接；

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

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

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

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

流程图如下所示：

 

 

 

6、工作流程

6.1 Leader工作流程

Leader主要有三个功能：

恢复数据；

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

Learner的消息类型主要有PING消息、REQUEST消息、ACK消息、REVALIDATE消息，根据不同的消息类型，进行不同的处理。

PING消息是指Learner的心跳信息；REQUEST消息是Follower发送的提议信息，包括写请求及同步请求；ACK消息是Follower的对提议的回复，超过半数的Follower通过，则commit该提议；REVALIDATE消息是用来延长SESSION有效时间

6.2 Follower工作流程

Follower主要有四个功能：

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

接收Leader消息并进行处理；

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

返回Client结果。

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

PING消息： 心跳消息；

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

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

UPTODATE消息：表明同步完成；

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

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

 

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

 

6.3 观察者（observer）

对于observer的流程不再叙述，observer流程和Follower的唯一不同的地方就是observer不会参加leader发起的投票。

————————————————
版权声明：本文为CSDN博主「N_bug」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_39082432/article/details/105755581