zookeeper集群（zookeeper集群状态查看）

本篇文章给大家谈谈zookeeper集群，以及zookeeper集群状态查看对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。

本文目录一览：

• 1、zookeeper高可用集群部署
• 2、zookeeper集群搭建方式
• 3、zookeeper集群原理简介

zookeeper高可用集群部署

一、Zookeeper 的搭建方式春顷吵

Zookeeper 安装方式有三种，单机模式和集群扒侍模式以及伪集群模式。

Zookeeper 通过复制来实现高可用性，只要集合体中半数以上的机器处于可用状态，它就能够保证服务继续。

为什么一定要超过半数呢？ 这跟 Zookeeper 的复制策略有关：Zookeeper 确保对 znode 树的每一个修改都会被复制到集合体中超过半数的机器上。

二、配置JDK环境

三、Zookeeper 单机模式搭建

1、下载 ZooKeeper ：

2、解压

3、配置环境变量

非必须操作

4、修改 Zookeeper 的配置文件 conf/zoo.cfg

5、启动 ZooKeeper

四、Zookeeper 集群模式搭建

Zookeeper 集群模式搭建方案：

1、解压

2、配置环境变量

非必须操作

3、修改 Zookeeper 的配置文件

zookeeper参数说明

A ：其中 A 是一个数字，表示这个是服务器的编号；乎坦B ：是这个服务器的 ip 地址；C ：Leader 选举的端口；D ：Zookeeper 服务器之间的通信端口。

4、添加服务器标识配置 dataDir/myid

5、将修改后的zookeeper分发到其他节点

6、启动

分别在3个节点启动zookeeper

查看状态

五、 Zookeeper 伪集群模式搭建

只需将zookeper复制3份到不同的位置，配置如下

zookeeper服务脚本

[img]

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集群搭建方式：粗搭培

zookeeper集群原理简介

以下举例三台集群的模型图：

当写数据的请求到达从节点的时候，请求会被转发到leader节点，由leader节点将数据同步到其他follower节点。所有的写操作有leader发起。

类似2PC（两阶段提交，需要等到所有节点返回ack），实际是ZAB协议的过半机制:

1、leader发起写事务给各个从节点，如上图的propose。

2、从节点收到写事务后，会对leader有一个应答ack。

3、leader收到半数以上的ack后（过半协议），发起事务提交commit。

当leader挂了，集群需要从其他的从节点选出一个新的leader。

在选举的过程中，有两个主要的信息：

1）myid：当前节点的id

2）zxid：当前事务的id

当选举发生时，需要去比较这两个信息的大小，选举的比较会发生很多轮，最终获胜的会被选举为leader。

如开篇图有三个节点，假设左侧节点的myid为1，leader的myid为2，右侧节点的myid为3。

当数据正在同步时发生了主节点宕机，这时候选举开始，可能存在以下情况：

左侧从节点可能存在的信息（myid，zxid）为：（1,101）；

右侧从节点可能存在的信息为：（3,102）；

这时候以上两个节点需要进行比较：

第一轮投票，所有的节点会优先投给自己，这时候投票比例是1:1，则需要对这两个节点的事务id进行pk比较，右侧节点的事务id大于左侧节点（事务id越大则表示数据越新，则丢失数据越仿世少），左侧节点pk失败了，进行下一轮投票。

第二轮投票开始，由于左侧节点上一轮pk失败，所以此次也投票给了右侧节点，此时右侧获得两票，超过型段了半数，所以右侧节点成为新节点。

当事务id相同时,则比较myid，当myid越大，则权重越大。

1）leader选举原理（myid，zxid）

2）集群消息广播（类似2PC-两阶段提交，无需全部节点ack，过半即发起commit）

脑裂：当集群分布在不同机房时，机房间可能卜大誉出现网络断开，这时候内部的节点是可以通信的，会导致每个机房内都选举出一个leader，导致脑裂。网络恢复后，就会有两个leader，数据如何合并，会导致问题。

奇数部署：过半机制

Quorums（ˈkwôrəm 法定人数） ，比如3个节点的集群，Quorums = 2, 也就是说集群可以容忍1个节点失效，这时候还能选举出1个lead，集群还可用。比如4个节点的集群，它的Quorums = 3，Quorums要超过3，相当于集群的容忍度还是1，如果2个节点失效，那么整个集群还是无效的

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