怎样进行Zookeeper原理解析

如何分析Zookeeper原理，针对这个问题，本文详细介绍了相应的分析和解答，希望能帮助更多想要解决这个问题的朋友找到更简单更容易的方法。

zookeeper角色

领导者:负责发起投票和更新系统状态，完成集群写操作和数据同步。

跟随者:参与投票，负责向领导转发写请求，接收客户请求和相应的客户查询。

观察者:不参加选举，向领导转发写请求，接收客户端请求，提高集群的读取和对应速度(可以忽略不计)。

Zookeeper核心

ZAB（Zookeeper Actomic BoardCost）协议：有两种模式（恢复模式与广播模式）

整个zookeeper集群只有一个节点，那就是Leader，它把客户端的写操作变成了什么东西(或者提出建议)。Leader节点再次写入数据后，会向所有的follower节点发送数据广播请求(或数据拷贝)，等待所有follower节点的反馈。在ZAB协议中，只要超过一半的跟随者节点反馈OK，Leader节点就会向所有跟随者服务器发送提交消息。也就是说，引导节点上的数据与跟随节点同步。

原理：

1.ZAB协议要求每个领导者经历三个阶段，即发现、同步和广播。

2.发现：动物园管理员集群需要选择一个领导者过程，领导者将维护一个可用的追随者列表。客户端可以在未来与该跟随者中的节点进行通信。

3.同步：领导负责与跟随者同步自己的数据，实现多副本存储。这也体现了CAP中的高可用性和分区容错性。Follower在消费完队列中未完成的请求后，将它们写入本地事务日志。

4.广播：领导者可以接受来自客户的新建议请求，并将新建议请求广播给所有追随者。

恢复模式（主节点选举：启动和崩溃恢复的情况下）

选举：

1.

Serverid:配置服务器时，给定服务器的id。

2.

Zxid:服务器在运行时生成数据id。zxid越大，数据越新。

3.

Epoch:选举的轮数，也就是逻辑时钟。随着选举轮数的增加

4.

Server状态:观察，跟随，观察，领导

步骤：

1.1。服务器刚刚启动(停机恢复或刚刚启动)并准备加入群集。这时，读取自己的信息如zxid。

2.当所有服务器都加入集群时，它们会推荐自己为领导者，然后将(领导者id、zixd、epoch)作为广播信息广播给集群中的所有服务器。然后等待集群中的服务器返回信息。

3.接收到集群中其他服务器返回的信息后，应该分为两类：服务器处于正在查看状态或其他状态。

(1)

服务器处于looking状态

首先判断逻辑时钟Epoch:

a)如果收到的纪元大于您当前的逻辑时钟(表示您保存的逻辑时钟已过期)。更新本地逻辑时钟Epoch，清除其他服务发送的选举数据(这些数据已经输出)。然后判断是否需要更新自己目前的选举情况(一开始选择的领导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来判断是否可以结束选举,如果可以也是保存逻辑时钟，设置选举状态，退出选举过程。

崩溃恢复：

新选举出来的leader不能包含未提交的proposal，即新选举的leader必须都是已经提交了的proposal的follower服务器节点。同时，新选举的leader节点中含有最高的ZXID。

• 广播模式（数据同步-类两阶段提交（2pc）,但是半数相应即可）

数据一致性：zookeeper采用ZAB协议的核心就是只要有一台服务器提交了proposal，就要确保所有的服务器最终都能正确提交proposal。这也是CAP/BASE最终实现一致性的一个体现。

性能：leader服务器与每个follower之间都有一个单独的队列进行收发消息，使用队列消息可以做到异步解耦。leader和follower之间只要往队列中发送了消息即可。如果使用同步方式容易引起阻塞。性能上要下降很多。

Proposal与ZXID：ZXID是一个长度64位的数字，其中低32位是按照数字递增，即每次客户端发起一个proposal,低32位的数字简单加1。高32位是leader周期的epoch编号，至于这个编号如何产生(我也没有搞明白)，每当选举出一个新的leader时，新的leader就从本地事物日志中取出ZXID,然后解析出高32位的epoch编号，进行加1，再将低32位的全部设置为0。这样就保证了每次新选举的leader后，保证了ZXID的唯一性而且是保证递增的。

具体步骤如下：

1. 客户端发起一个写操作请求

2. Leader服务器将客户端的request请求转化为事物proposql提案，同时为每个proposal分配一个全局唯一的ID，即ZXID。

3. leader服务器与每个follower之间都有一个队列，leader将消息发送到该队列

4. follower机器从队列中取出消息处理完(写入本地事物日志中)毕后，向leader服务器发送ACK确认。

5. leader服务器收到半数以上的follower的ACK后，即认为可以发送commit

6. leader向所有的follower服务器发送commit消息。

关于怎样进行Zookeeper原理解析问题的解答就分享到这里了，希望