zookeeper最新版本（zookeeper稳定版本）

本篇文章给大家谈谈zookeeper最新版本，以及zookeeper稳定版本对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、Zookeeper通信协议
• 2、zookeeper集群搭建方式
• 3、Zookeeper的选举机制理论总结
• 4、Zookeeper的脑裂问题及解决方案

Zookeeper通信协议

我们这里的讨论是建立在版本3.4.6的基础之上的。

zookeeper-3.4.6.jar下，有一个单独的目录，叫proto，这个就是zookeeper通信协议的主要实现源码。我们的讨论，就是建立在这些源码之上的。

一，请求/响应协议报文结构

Zookeeper的请求/响应协议报文结构简单来说由3部分组成。

len：报文长度。

报文头：请求报文头/响应报文头。

报文体：请求报文体/响应报文体。

请求报文详细结构如下：

各个属性字段的含义：

len：整个请求数据包的长度，占3个字节。

xid：请求头的一部分，代表客户端请求的发起序号。什么意思呢？我的理解就是标识客户端的请求次数。

type：请求头的一部分，客户端请求类型，type值为4代表的是OpCode.getData。

请求体中的len：请求体的长度。

path：报文体的一部分，代表节点路径

watch：报文体的一部分，代表是否注册watch，值为1代表注册，值为0代表不注册。

响应报文详细结构如下：

图片稍后补上。

各个属性字段的含义：

len：整个请求数据包的长度，占3个字节。

xid：报文头的一郑耐部分，代表客户端请求的发起序号。什么意思呢？我的理解就是标识客户端的请求次数。代表客户端会话创建后，发送的第N次请求。

zxid，报文头的一部分，代表当前服务端处理过的最新的时间戳值。

err，报文头的一部分，代表错误码，0代表Code.OK。

报文体中的len：报文体的一部分，代表报文体的长度。

data，报文体的一部分，代表节点的数据内容。

czxid，报文体的一部分，代表创建该节点时的zxid。

mzxid，报文体的一部分，代表最后一次修改该节点时的zxid。

ctime，报文体的一部分，代表节点的创建时间。

mtime，报文体的一部分，代表最后一次修改该节点时的时间。

version，报文体的一部分，代表节点的内容的版本号。

cversion，报文体的一部分，代表节点的子节点的版本号。

aversion，报文体的一部分，代表节点的ACL变更版本号。

ephemeralOwner，报文体的一部分，如果节点是临时节点，则记录创建该临时节点的会话ID，如果是持久节点，则为0。

dataLength，报文体的一部分，代表节点的内容长度。

numChildren，报文体的一部分，代表节点的子节点个数。

pzxid，报文体的一部分，代表最后一次对子节点列表变更的pzxid。

二，请求/响应协议具体实现

重点衫扒关注以下几个类：

请求报文头实现类

RequestHeader

响应报文头实现类

ReplyHeader

创建连接的协议实现类

ConnectRequest

ConnectResponse

请求节点数据的协议实现类

GetDataRequest

GetDataResponse

创建节点的协议实现类

CreateRequest

CreateResponse

更新节点数据的协议实现类

SetDataRequest

SetDataResponse

这些类都继承了Zookeeper的序列化接口Record，因为再进行网络传输前，都要先进行序列化。

首先来看创建连接的协议实现类

ConnectRequest定义了5个字段，分别是：

protocalVersion，协议的版本号。

lastZxidSeen，最近一次接收到的服务器ZXID。

timeOut，会话超时时间。

sessionId，会话标识。

passwd，会话密码。

ConnectResponse定义了2个字段，分别是：

data：节点的数据。

stat：节点的状态。

其他的协议都和这个类似，这里不在赘述。另外需要注意，报文头是单喊塌春独定义的，和报文体是分开的。因为报文头是公用的，抽取出来单独定义，方便复用。

Zookeeper通信协议这一块内容相对而言还是简单的。主要内容就是定义Zookeeper节点之间通信的细节和序列化反序列化方式，是Zookeeper集群的基础，后续集群的各种操作都是都是通过这些通信协议来工作的。

zookeeper集群搭建方式

本次搭建版本是：zookeeper-3.4.14.tar.gz（以下在每台服务器都需要部署一遍）

1，将zookeeper-3.4.14.tar.gz 拷贝到服务器（本次集群是3台）指定文件夹位置。

        解压 tar -zxvf zookeeper-3.4.14.tar.gz   让后修改名称 mv zookeeper-3.4.14 zookeeper

2，进入到zookeeper目录。

3，然后在/etc/profile 增加zookeeper环境变量

4，进入到conf目录下面。修改zoo_sample.cfg 文件名

    执行命令：mv zoo_sample.cfg zoo.cfg

5，编辑zoo.cfg文件

    执行命令：vim zoo.cfg 

    1》修改dataDir 为zookeeper下面的data（该文件需要自己创建）

    2》clientPort 默认是2181 （此处有端口占用，所有我这边改成2182）

    3》在文件最后面加入集群（岩唯此处三台集群为什么这样加，暂时枝哗没有研究）

    server.0=ip1:2888:3888

    server.1=ip2:2888:3888

    server.2=ip3:2888:3888

6，在5中dataDir的目录下面新建myid文件，文件内容是当前zk的节点

7，启动每台服务器的zk服务节点，在bin目录下执行（添加环境变量的话可以在任意位置执行）

    执行命令：./zkServer.sh start（./zkServer.sh stop是停止）

    启动成功后 查看是否启动起来：

        执行命令：ps aux | grep 'zookeeper' 或者 jps

8，查看三台机器主从身份（leader 主 follower从）

至此zk集群搭建成功。

kafka集群搭建方式：粗搭培

[img]

Zookeeper的选举机制理论总结

这篇文章我们重点理解Zookeeper选举机制的思路。

一，Zookeeper选举过程中服务器的状态。

LOOKING：寻找leader状态，该状态下，服务器认为当前集群没有leader，会发起leader选举。在选举过程中，所有服务器的状态都是LOOKING。

FOLLOWING：跟随者状态，该状态下，当前服务器是follower，并且知道leader是谁。此时选举已经结束。

LEADING：领导者状态，该状态下，当前服务器是leader，会与follower维持心跳检测。此时选举已经结束。

OBSERVING：观察者状态，该状态下的服务器是observer，不参与选举。

二，Zookeeper选票数据结构

每个服务器在进行leader选举时，都会发送以下几个关键属性信息：

logicalclock：投票轮次，自增的，volatile的，初始值为1，也就是第一轮选举。

state：当前服务器的状态。

self_id：当前服务器的myid。

self_zxid：当前服务器的最新的zxid。

vote_id：当前服务器推举的leader服务器的myid。

vote_zxid：当前服务器推举的leader服务器的最新的zxid。

三，Zookeeper选举算法

从3.4.0版本开始，Zookeeper使用FastLeaderElection选举算法，可以解决之前的LeaderElection算法收敛慢的问题。更为重要的是，FastLeaderElection算法解决了脑裂问题，保证leader的唯一性。也就是说，从Zookeeper3.4.0版本开始，Zookeeper可能存在的问题只有2个了：

1，客户端没有缓存。

2，没有自我保护机制。

四，Zookeeper选举流程

1，自增选举轮次。

Zookeeper选举机制有一个前提条件：在一个轮次的选举中，所有选票必须属于该轮次。在选举的某一时刻，确实可能存在某张选票不属于该轮次的情况。所以Zookeeper在选举过程中，始终会先核对选票的轮次。

2，初始化选票。

每个服务器在广播自己的选票时，都会先清空投票箱，这个投票箱存放的是所有接收到的来自腊毕喊其他服务器的选票。投票箱中只记录每个服务器的最后一次投票，如果服务器更新自己的投票，则其他服务器会更新该服务器的选票。

举个例子：服务器2投票给服务器3，服务器3投票给服务器1，则服务器1的投票箱中有如下记录

(2,3),(3,1),(1,1)

当然，这里的选票的结构是简化版的，如果加上选举轮次logicalclock，可能是数茄这样的：

(8,2,3),(8,3,1),(8,1,1)

第一位代表当前的选举轮次，第8轮选举。

3，发送初始化选票。

每个服务器在投票开始阶段，都把票投给自己，然后通过广播通知其他服务器。

4，接收外部选票。

每台服务器都会尝试从其他服务器获取选票，并保存到自己的投票箱。

5，判断选举轮次logicalclock。

确保是同一轮次的投票。如果当前服务器发现自己的轮次落后了，则自增logicalclock，然后重新发送广播告诉其他服务器。

6，选票PK确认自己最终的投票。

注意，在这个阶段，每台服务器都可能改变自己的想法，重新确定把选票投给谁。

有3条规则：

第一条规则：如果当前服务器的logicalclock小于其他服务器，说明自己的选举轮次过期了，此时更新自己的logicalclock，然后重新把自己的选票发送出去。

第二条规则：如果当前服务器的logicalclock等于其他服务器，说明大家进行的是同一轮次的选举，此时比较二者的vote_zxid，轮野vote_zxid大者获胜。如果当前服务器输了，则更新自己的投票为胜者，然后广播告诉其他服务器。

第三条规则：如果当前服务器的logicalclock等于其他服务器，说明大家进行的是同一轮次的选举，此时比较二者的vote_zxid，如果vote_zxid也相等，则比较二者的vote_myid，vote_myid大者获胜。如果当前服务器输了，则更新自己的投票为胜者，然后广播告诉其他服务器。

7，统计选票。

如果已经确定有过半服务器认可了自己的投票，则终止投票。否则继续接收其他服务器的投票。

8，更新服务器状态。

投票结束后，服务器更新自己的状态serverState，如果投给自己的选票过半了，则将自己更新为LEADING，否则将自己更新为FOLLOWING。

这里思考一个问题：Zookeeper启动阶段，myid最大的服务器是不是一定会被选举为leader？

Zookeeper的脑裂问题及解决方案

先抛吵简坦出一个问题：Zookeeper3.4.6版本是否存在脑裂问题？

一，什么是脑裂

什么是脑裂呢？

下图是一个正常的Zookeeper集群，由7个节点组成。其中有1个Leader A和6个Follower。

当网络发送故障时，Follower D、Follower E、Follower F从集群中断开了，然后这3个节点认为Leader挂了，然后重新选了1个Leader，Follower E变成了Leader B，如下图，这就是脑裂。

上图有可能存在一个问题，因为Zookeeper集群的一个特性是：过半节点存活可用。如何理解。网上有一个说法：有100个节点组成的集群，如果被网络分割成50和50两个分区，那么整个集群是不可用的，因为不满足过半节点存活可用的原则。

二，Zookeeper3.4.6版本是否存在脑裂问题

首先，Zookeeper3.4.6不存在脑裂的问题。

为什么呢升桐？

Zookeeper3.4.6的选举算咐迅法是FastLeaderElection，该算法的规则是投票超过半数的服务器才能当选为Leader。这个算法能够保证leader的唯一性。

关于zookeeper最新版本和zookeeper稳定版本的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。