zookeeper最新版本（zookeeper version）

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

本文目录一览：

• 1、zookeeper集群搭建方式
• 2、Zookeeper的脑裂问题及解决方案
• 3、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的脑裂问题及解决方案

先抛吵简坦出一个问题：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通信协议

我们这里的讨论是建立在版本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 version的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。