zookeeper选举和ZAB协议

古城微笑少年丶 2022-02-15 03:28 358阅读 0赞

# **前言** #

为了高可用和数据安全起见，zk集群一般都是由几个节点构成(由n/2+1，投票机制决定，肯定是奇数个节点)。多节点证明它们之间肯定会有数据的通信，同时，为了能够使zk集群对外是透明的，一个整体对外提供服务，那么客户端访问zk服务器的数据肯定是要数据同步，也即**数据一致性**。

zk集群是Leader/Follower模式来保证数据同步的。整个集群同一时刻只能有一个Leader，其他都是Follower或Observer。Leader是通过选举选出来的，这里涉及到ZAB协议(原子消息广播协议)。

### 1.ZAB协议 ###

为了更好理解下文，先说ZAB协议，它是选举过程和数据写入过程的基石。ZAB的核心是定义会改变zk服务器数据状态的事务请求的处理方式。

**ZAB的理解：**所有事务请求是由一个全局唯一的服务器来协调处理，这个的服务器就是Leader服务器，其它服务器都是Follower服务器或Observer服务器。Leader服务器负责将一个客户端的请求转换成那个一个**事务Proposalͧ(提议)**，将该Proposal分发给集群中所有的Follower服务器。然后Leader服务器需要等待所有Follower服务器的应答，当Leader服务器收到超过**半数**的Follower服务器进行了明确的应答后，Leader会再次向所有的Follower服务器分发Commit消息，要求其将前一个Proposal进行提交。

注意**事务提议**这个词，就类似 **人大代表大会提议** ，提议就代表会有应答，之间有通信。因此在zk的ZAB协议为了可靠性和可用性，会有**投票**，**应答**等操作来保证整个zk集群的正常运行。

总的来说就是，涉及到客户端对zk集群数据改变的行为都先由Leader统一响应，然后再把请求转换为事务转发给其他所有的Follower，Follower应答并处理事务，最后再反馈。如果客户端只是读请求，那么zk集群所有的节点都可以响应这个请求。

1.  ZAB协议是专门为zookeeper实现分布式协调功能而设计。zookeeper主要是根据ZAB协议是实现分布式系统**数据一致性**。
2.  zookeeper根据ZAB协议建立了主备模型完成zookeeper集群中数据的同步。这里所说的主备系统架构模型是指，在zookeeper集群中，只有一台leader负责处理外部客户端的事物请求(或写操作)，然后leader服务器将客户端的写操作数据同步到所有的follower节点中。
    
    ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70][]
3.  ZAB的协议核心是在整个zookeeper集群中只有一个节点即Leader将客户端的写操作转化为事物(或提议proposal)。Leader节点再数据写完之后，将向所有的follower节点发送数据广播请求(或数据复制)，等待所有的follower节点反馈。在ZAB协议中，只要超过半数follower节点反馈OK，Leader节点就会向所有的follower服务器发送commit消息。即将leader节点上的数据同步到follower节点之上。 
    
    ![这里写图片描述][SouthEast]
4.  ZAB协议中主要有两种模式，第一是消息广播模式；第二是崩溃恢复模式

### **消息广播模式** ###

1.  在zookeeper集群中数据副本的传递策略就是采用消息广播模式。zookeeper中数据副本的同步方式与二阶段提交相似但是却又不同。二阶段提交的要求协调者必须等到所有的参与者全部反馈ACK确认消息后，再发送commit消息。要求所有的参与者要么全部成功要么全部失败。二阶段提交会产生严重阻塞问题。
2.  ZAB协议中Leader等待follower的ACK反馈是指”只要半数以上的follower成功反馈即可，不需要收到全部follower反馈”
3.  图中展示了消息广播的具体流程图 
    
    ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70 1][]
4.  zookeeper中消息广播的具体步骤如下：   
    4.1. 客户端发起一个写操作请求   
    4.2. Leader服务器将客户端的request请求转化为事物proposql提案，同时为每个proposal分配一个全局唯一的ID，即ZXID。   
    4.3. leader服务器与每个follower之间都有一个队列，leader将消息发送到该队列   
    4.4. follower机器从队列中取出消息处理完(写入本地事物日志中)毕后，向leader服务器发送ACK确认。   
    4.5. leader服务器收到半数以上的follower的ACK后，即认为可以发送commit   
    4.6. leader向所有的follower服务器发送commit消息。
5.  zookeeper采用ZAB协议的核心就是只要有一台服务器提交了proposal，就要确保所有的服务器最终都能正确提交proposal。这也是CAP/BASE最终实现一致性的一个体现。
6.  leader服务器与每个follower之间都有一个单独的队列进行收发消息，使用队列消息可以做到异步解耦。leader和follower之间只要往队列中发送了消息即可。如果使用同步方式容易引起阻塞。性能上要下降很多。

### 崩溃恢复 ###

1.  zookeeper集群中为保证任何所有进程能够有序的顺序执行，只能是leader服务器接受写请求，即使是follower服务器接受到客户端的请求，也会转发到leader服务器进行处理。
2.  如果leader服务器发生崩溃，则zab协议要求zookeeper集群进行崩溃恢复和leader服务器选举。
3.  ZAB协议崩溃恢复要求满足如下2个要求：   
    **3.1. 确保已经被leader提交的proposal必须最终被所有的follower服务器提交。   
    3.2. 确保丢弃已经被leader出的但是没有被提交的proposal。**
4.  根据上述要求，新选举出来的leader不能包含未提交的proposal，即新选举的leader必须都是已经提交了的proposal的follower服务器节点。同时，新选举的leader节点中含有最高的ZXID。这样做的好处就是可以避免了leader服务器检查proposal的提交和丢弃工作。
5.  leader服务器发生崩溃时分为如下场景：   
    5.1. leader在提出proposal时未提交之前崩溃，则经过崩溃恢复之后，新选举的leader一定不能是刚才的leader。因为这个leader存在未提交的proposal。   
    5.2 leader在发送commit消息之后，崩溃。即消息已经发送到队列中。经过崩溃恢复之后，参与选举的follower服务器(刚才崩溃的leader有可能已经恢复运行，也属于follower节点范畴)中有的节点已经是消费了队列中所有的commit消息。即该follower节点将会被选举为最新的leader。剩下动作就是数据同步过程。

### 数据同步 ###

1.  在zookeeper集群中新的leader选举成功之后，leader会将自身的提交的最大proposal的事物ZXID发送给其他的follower节点。follower节点会根据leader的消息进行回退或者是数据同步操作。最终目的要保证集群中所有节点的数据副本保持一致。
2.  数据同步完之后，zookeeper集群如何保证新选举的leader分配的ZXID是全局唯一呢？这个就要从ZXID的设计谈起。   
    2.1 ZXID是一个长度64位的数字，其中低32位是按照数字递增，即每次客户端发起一个proposal,低32位的数字简单加1。高32位是leader周期的epoch编号，至于这个编号如何产生(我也没有搞明白)，每当选举出一个新的leader时，新的leader就从本地事物日志中取出ZXID,然后解析出高32位的epoch编号，进行加1，再将低32位的全部设置为0。这样就保证了每次新选举的leader后，保证了ZXID的唯一性而且是保证递增的。

### 2.Zookeeper服务器 ###

**2.1 zk服务器角色**

*  Leader

1.  事务请求的唯一调度和处理者，保证集群事务处理的顺序序性
2.  集群内部各服务器的调度者

*  Follower

1.  处理客户端非事务请求，转发事务请求给Leader服务器
2.  参与事务请求Proposal的投票
3.  参与Leader的选举投票

*  Observer

1.  处理客户端非事务请求，转发事务请求给Leader服务器
2.  不参加任何形式的投票，包括选举和事务投票(超过半数确认)
3.  Observer的存在是为了提高zk集群对外提供读性能的能力

整个zk集群的角色作用如下图：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70 2][]

**2.2 zk服务器状态**

*  LOOKING

1.  寻找Leader状态
2.  当服务器处于这种状态时，表示当前没有Leader，需要进入选举流程

*  FOLLOWING

1.  从机状态，表明当前服务器角色是Follower

*  OBSERVING

1.  观察者状态，表明当前服务器角色是Observer

*  LEADING

1.  领导者状态，表明当前服务器角色是Leader
2.  ServerState 类维护服务器四种状态。

zk服务器的状态是随着机器的变化而变化的。比如Leader宕机了，服务器状态就变为LOOKING，通过选举后，某机器成为Leader，服务器状态就转换为LEADING。其他情况类似。

**2.3 Leader选举概述**

**参考:** [https://blog.csdn.net/zhoulixin8/article/details/51751567][https_blog.csdn.net_zhoulixin8_article_details_51751567]

Leader选举是保证分布式数据一致性的关键所在。当Zookeeper集群中的一台服务器出现以下两种情况之一时，需要进入Leader选举。

*  (1) 服务器初始化启动。
 *  (2) 服务器运行期间无法和Leader保持连接。

下面就两种情况进行分析讲解。

**1. 服务器启动时期的Leader选举**

若进行Leader选举，则至少需要两台机器，这里选取3台机器组成的服务器集群为例。在集群初始化阶段，当有一台服务器Server1启动时，其单独无法进行和完成Leader选举，当第二台服务器Server2启动时，此时两台机器可以相互通信，每台机器都试图找到Leader，于是进入Leader选举过程。选举过程如下

**(1) 每个Server发出一个投票**。由于是初始情况，Server1和Server2都会将自己作为Leader服务器来进行投票，每次投票会包含所推举的服务器的myid和ZXID，使用**(myid, ZXID)**来表示，此时Server1的投票为(1, 0)，Server2的投票为(2, 0)，然后各自将这个投票发给集群中其他机器。

**(2) 接受来自各个服务器的投票**。集群的每个服务器收到投票后，首先判断该投票的有效性，如检查是否是本轮投票、是否来自LOOKING状态的服务器。

**(3) 处理投票**。针对每一个投票，服务器都需要将别人的投票和自己的投票进行PK，PK规则如下

1.  **优先检查ZXID**。ZXID比较大的服务器优先作为Leader。zxid随着数据变化而增大。
2.  **如果ZXID相同，那么就比较myid**。myid较大的服务器作为Leader服务器。

对于Server1而言，它的投票是(1, 0)，接收Server2的投票为(2, 0)，首先会比较两者的ZXID，均为0，再比较myid，此时Server2的myid最大，于是更新自己的投票为(2, 0)，然后重新投票，对于Server2而言，其无须更新自己的投票，只是再次向集群中所有机器发出上一次投票信息即可。

**(4) 统计投票**。每次投票后，服务器都会统计投票信息，判断是否已经有过半机器接受到相同的投票信息，对于Server1、Server2而言，都统计出集群中已经有两台机器接受了(2, 0)的投票信息，此时便认为已经选出了Leader。

**(5) 改变服务器状态**。一旦确定了Leader，每个服务器就会更新自己的状态，如果是Follower，那么就变更为FOLLOWING，如果是Leader，就变更为LEADING。

**2. 服务器运行时期的Leader选举**

那么，初始化的时候，是按照上述的说明进行选举的，但是当zookeeper运行了一段时间之后，有机器down掉，重新选举时，选举过程就相对复杂了。需要加入数据zxid、mid和逻辑时钟。

逻辑时钟：这个值从0开始递增,每次选举对应一个值,也就是说: 如果在同一次选举中,那么这个值应该是一致的 ; 逻辑时钟值越大,说明这一次选举leader的进程更新.

选举的标准就变成：

*  1. 逻辑时钟小的选举结果被忽略，重新投票，为了保证投票的是同一个选举会议。
 *  2. 统一逻辑时钟后，zxid大的胜出。
 *  3. 数据id相同的情况下，myid大的胜出。

根据这个规则选出leader。

**2.4 zk服务器通信**

集群嘛，节点之间肯定是要通信的。zokeeper通信有两个特点：

*  1.使用的通信协议是**TCP协议**。在集群中到底是怎么连接的呢？还记得在配置zookeeper时要创建一个data目录并在其他创建一个myid文件并写入唯一的数字吗？zk服务器的TCP连接方向就是依赖这个myid文件里面的数字大小排列。数小的向数大的发起TCP连接。比如有3个节点，myid文件内容分别为1,2,3。zk集群的tcp连接顺序是1向2发起TCP连接，2向3发起TCP连接。如果有n个节点，那么tcp连接顺序也以此类推。这样整个zk集群就会连接起来。
 *  2.zk服务器是多端口的。例如配置如下：

tickTime=2000
      dataDir=/home/liangjf/app/zookeeper/data
      dataLogDir=/home/liangjf/app/zookeeper/log
      clientPort=2181
      initLimit=5
      syncLimit=2
      server.1=192.168.1.1:2888:3888
      server.2=192.168.1.2:2888:3888
      server.3=192.168.1.3:2888:3888

*  第1个端口是通信和数据同步端口，默认是2888
 *  第2个端口是投票端口，默认是3888

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70]: /images/20220215/fc95d37ee1ba426ab8e5ed11e9346f2b.png
[SouthEast]: /images/20220215/04c2010b82a54c1b972d5e8d5c23e124.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70 1]: /images/20220215/11bb296a88d0473fbd8ec6a10e434844.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ppblhZYW4_size_16_color_FFFFFF_t_70 2]: /images/20220215/73c211242c9d4e328e5606d58243b07a.png
[https_blog.csdn.net_zhoulixin8_article_details_51751567]: https://blog.csdn.net/zhoulixin8/article/details/51751567