转载：深刻浅出Zookeeper

 

ZAB协议

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

          

消息广播模式

1. 在zookeeper集群中数据副本的传递策略就是采用消息广播模式。zookeeper中数据副本的同步方式与二阶段提交类似可是却又不一样。二阶段提交的要求协调者必须等到全部的参与者所有反馈ACK确认消息后，再发送commit消息。要求全部的参与者要么所有成功要么所有失败。二阶段提交会产生严重阻塞问题。
2. ZAB协议中Leader等待follower的ACK反馈是指”只要半数以上的follower成功反馈便可，不须要收到所有follower反馈”
3. 图中展现了消息广播的具体流程图 
   
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的惟一性并且是保证递增的。 
   

 

 

ZAB协议原理

1. ZAB协议要求每一个leader都要经历三个阶段，即发现，同步，广播。
2. 发现：即要求zookeeper集群必须选择出一个leader进程，同时leader会维护一个follower可用列表。未来客户端能够这follower中的节点进行通讯。
3. 同步：leader要负责将自己的数据与follower完成同步，作到多副本存储。这样也是体现了CAP中高可用和分区容错。follower将队列中未处理完的请求消费完成后，写入本地事物日志中。
4. 广播：leader能够接受客户端新的proposal请求，将新的proposal请求广播给全部的follower。

Zookeeper设计目标

1. zookeeper做为当今最流行的分布式系统应用协调框架，采用zab协议的最大目标就是创建一个高可用可扩展的分布式数据主备系统。即在任什么时候刻只要leader发生宕机，都能保证分布式系统数据的可靠性和最终一致性。
2. 深入理解ZAB协议，才能更好的理解zookeeper对于分布式系统建设的重要性。以及为何采用zookeeper就能保证分布式系统中数据最终一致性，服务的高可用性。

 

 

这篇主要分析leader的选主机制，zookeeper提供了三种方式：

• LeaderElection
• AuthFastLeaderElection
• FastLeaderElection

默认的算法是FastLeaderElection，因此这篇主要分析它的选举机制。

选择机制中的概念

服务器ID

好比有三台服务器，编号分别是1,2,3。

编号越大在选择算法中的权重越大。

数据ID

服务器中存放的最大数据ID.

值越大说明数据越新，在选举算法中数据越新权重越大。

逻辑时钟

或者叫投票的次数，同一轮投票过程当中的逻辑时钟值是相同的。每投完一次票这个数据就会增长，而后与接收到的其它服务器返回的投票信息中的数值相比，根据不一样的值作出不一样的判断。

选举状态

• LOOKING，竞选状态。
• FOLLOWING，随从状态，同步leader状态，参与投票。
• OBSERVING，观察状态,同步leader状态，不参与投票。
• LEADING，领导者状态。

选举消息内容

在投票完成后，须要将投票信息发送给集群中的全部服务器，它包含以下内容。

• 服务器ID
• 数据ID
• 逻辑时钟
• 选举状态

选举流程图

由于每一个服务器都是独立的，在启动时均从初始状态开始参与选举，下面是简易流程图。

 

 

 

下面详细解释一下这个流程：

首先给出几个名词定义：

（1）Serverid：在配置server时，给定的服务器的标示id。

（2）Zxid:服务器在运行时产生的数据id，zxid越大，表示数据越新。

（3）Epoch：选举的轮数，即逻辑时钟。随着选举的轮数++

（4）Server状态：LOOKING,FOLLOWING,OBSERVING,LEADING

 

 

步骤：

1、  Server刚启动（宕机恢复或者刚启动）准备加入集群，此时读取自身的zxid等信息。

2、  全部Server加入集群时都会推荐本身为leader，而后将（leader id 、 zixd 、 epoch）做为广播信息，广播到集群中全部的服务器(Server)。而后等待集群中的服务器返回信息。

3、  收到集群中其余服务器返回的信息，此时要分为两类：该服务器处于looking状态，或者其余状态。

（1）    服务器处于looking状态

首先判断逻辑时钟 Epoch:

a)     若是接收到Epoch大于本身目前的逻辑时钟（说明本身所保存的逻辑时钟落伍了）。更新本机逻辑时钟Epoch，同时 Clear其余服务发送来的选举数据（这些数据已经OUT了）。而后判断是否须要更新当前本身的选举状况（一开始选择的leader id 是本身）

    判断规则rules judging：保存的zxid最大值和leader Serverid来进行判断的。先看数据zxid,数据zxid大者胜出;其次再判断leaderServerid, leader Serverid大者胜出；而后再将自身最新的选举结果(也就是上面提到的三种数据（leader Serverid，Zxid，Epoch）广播给其余server)

b)     若是接收到的Epoch小于目前的逻辑时钟。说明对方处于一个比较OUT的选举轮数，这时只须要将本身的 （leader Serverid，Zxid，Epoch）发送给他便可。

c)     若是接收到的Epoch等于目前的逻辑时钟。再根据a)中的判断规则，将自身的最新选举结果广播给其余 server。

 

同时Server还要处理2种状况：

a)    若是Server接收到了其余全部服务器的选举信息，那么则根据这些选举信息肯定本身的状态（Following,Leading），结束Looking，退出选举。

b)   即便没有收到全部服务器的选举信息，也能够判断一下根据以上过程以后最新的选举leader是否是获得了超过半数以上服务器的支持，若是是则尝试接受最新数据，假若没有最新的数据到来，说明你们都已经默认了这个结果,一样也设置角色退出选举过程。

 

（2）    服务器处于其余状态（Following, Leading）

a)     若是逻辑时钟Epoch相同,将该数据保存到recvset,若是所接收服务器宣称本身是leader,那么将判断是否是有半数以上的服务器选举它,若是是则设置选举状态退出选举过程

b)     不然这是一条与当前逻辑时钟不符合的消息，那么说明在另外一个选举过程当中已经有了选举结果，因而将该选举结果加入到outofelection集合中，再根据outofelection来判断是否能够结束选举,若是能够也是保存逻辑时钟，设置选举状态，退出选举过程。

以上就是FAST选举过程。

 

 

 转载至 https://blog.csdn.net/a724888/article/details/80757503 感受应该是全网最好的了。