Zookeeper-集群架构

Zookeeper集群架构

集群角色

• Leader： 领导者

事务请求（写操作）的唯一调度者和处理者，保证集群事务处理的顺序性；集群内部各个服务器的调度者。对于create、setData、delete等有写操作的请求，则要统一转发给leader处理，leader需要决定编号、执行操作，这个过程称为事务。

• Follower: 跟随者

处理客户端非事务（读操作）请求（可以直接响应），转发事务请求给Leader；参与集群Leader选举投票。

• Observer: 观察者

对于非事务请求可以独立处理（读操作），对于事务性请求会转发给leader处理。Observer节点接收来自leader的inform信息，更新自己的本地存储，不参与提交和选举投票。通常在不影响集群事务处理能力的前提下提升集群的非事务处理能力。

#配置一个ID为3的观察者节点：server.3=192.168.0.3:2888:3888:observer

Observer应用场景：

• 提升集群的读性能。因为Observer和不参与提交和选举的投票过程，所以可以通过往集群里面添加observer节点来提高整个集群的读性能。

• 跨数据中心部署。 比如需要部署一个北京和上海两地都可以使用的zookeeper集群服务，并且要求北京和香港客户的读请求延迟都很低。解决方案就是把香港的节点都设置为observer。

集群架构

leader节点可以处理读写请求，follower只可以处理读请求。follower在接到写请求时会把写请求转发给leader来处理。

Zookeeper数据一致性保证：

• 全局可线性化(Linearizable )写入：先到达leader的写请求会被先处理，leader决定写请求的执行顺序。

• 客户端FIFO顺序：来自给定客户端的请求按照发送顺序执行。

三节点Zookeeper集群搭建

环境准备：三台虚拟机

192.168.65.163192.168.65.184192.168.65.186

修改zoo.cfg配置，添加server节点配置

# 修改数据存储目录dataDir=/data/zookeeper#三台虚拟机 zoo.cfg 文件末尾添加配置server.1=192.168.65.163:2888:3888server.2=192.168.65.184:2888:3888server.3=192.168.65.186:2888:3888

server.A=B:C:D

A 是一个数字，表示这个是第几号服务器； 集群模式下配置一个文件 myid，这个文件在 dataDir 目录下，这个文件里面有一个数据 就是 A 的值，Zookeeper 启动时读取此文件，拿到里面的数据与 zoo.cfg 里面的配置信息比较从而判断到底是哪个server。

B 是这个服务器的地址；

C 是这个服务器Follower与集群中的Leader服务器交换信息的端口；

D 是万一集群中的Leader服务器挂了，需要一个端口来重新进行选举，选出一个新的Leader，而这个端口就是用来执行选举时服务器相互通信的端口。

创建 myid 文件，配置服务器编号

在dataDir对应目录下创建 myid 文件，内容为对应ip的zookeeper服务器编号，并且上下左右不要有空格

注意：添加 myid 文件，一定要在 Linux 里面创建，在 notepad++里面很可能乱码

启动zookeeper server集群

启动前需要关闭防火墙(生产环境需要打开对应端口)

# 分别启动三个节点的zookeeper serverbin/zkServer.sh start# 查看集群状态bin/zkServer.sh status#centos7 # 检查防火墙状态systemctl status firewalld#关闭防火墙systemctl stop firewalldsystemctl disable firewalld

Zookeeper四字命令使用

用户可以使用Zookeeper四字命令获取 zookeeper 服务的当前状态及相关信息。用户在客户端可以通过 nc（netcat） 向 zookeeper 提交相应的命令。

安装 nc 命令：# centos yum install nc四字命令格式：echo [command] | nc [ip] [port]

ZooKeeper 常用四字命令主要如下：

ZooKeeper: Because Coordinating Distributed Systems is a Zoo

开启四字命令

//方法1： 在zoo.cfg 文件里加入配置项让这些指令放行#开启四字命令4lw.commands.whitelist=*//方法2：在zk的启动脚本zkServer.sh中新增放行指令#添加JVM环境变量-Dzookeeper.4lw.commands.whitelist=*ZOOMAIN="-Dzookeeper.4lw.commands.whitelist=* ${ZOOMAIN}"

stat 命令

stat 命令用于查看 zk 的状态信息，实例如下：

 echo stat | nc 192.168.65.186 2181

ruok 命令

ruok 命令用于查看当前 zkserver 是否启动，若返回 imok 表示正常。

echo ruok | nc 192.168.65.186 2181

Zookeeper选举原理

ZooKeeper的Leader选举过程是基于投票和对比规则的，确保集群中选出一个具有最高优先级的服务器作为Leader来处理客户端请求。以服务启动期间选举为例：

投票对比规则：

• 首先比较epoch，选取具有最大epoch的服务器。epoch用于区分不同的选举轮次，每次重新选举时都会增加epoch。

• 如果epoch相同，则比较zxid（事务ID），选取事务ID最大的服务器。zxid表示最后一次提交的事务ID。

• 如果zxid也相同，则比较myid（服务器ID），选取服务器ID最大的服务器。

/** * Check if a pair (server id, zxid) succeeds our * current vote. * */protected boolean totalOrderPredicate(long newId, long newZxid, long newEpoch, long curId, long curZxid, long curEpoch) {LOG.debug("id: {}, proposed id: {}, zxid: 0x{}, proposed zxid: 0x{}",newId,curId,Long.toHexString(newZxid),Long.toHexString(curZxid));if (self.getQuorumVerifier().getWeight(newId) == 0) {return false;}/* * We return true if one of the following three cases hold: * 1- New epoch is higher * 2- New epoch is the same as current epoch, but new zxid is higher * 3- New epoch is the same as current epoch, new zxid is the same *as current zxid, but server id is higher. */return ((newEpoch > curEpoch)|| ((newEpoch == curEpoch)&& ((newZxid > curZxid)|| ((newZxid == curZxid)&& (newId > curId)))));}

zxid的数据结构

根据这个工具类，可以得出zxid的数据结构的一些信息。

1、zxid是一个64位的整数，由高32位的epoch和低32位的counter组成。

2、epoch表示ZooKeeper服务器的逻辑时期（logical epoch），它是一个相对时间的概念，用于区分不同的Leader选举周期。

3、counter是一个在每个时期（epoch）内递增的计数器，用于标识事务的顺序。

public class ZxidUtils {public static long getEpochFromZxid(long zxid) {return zxid >> 32L;}public static long getCounterFromZxid(long zxid) {return zxid & 0xffffffffL;}public static long makeZxid(long epoch, long counter) {return (epoch << 32L) | (counter & 0xffffffffL);}public static String zxidToString(long zxid) {return Long.toHexString(zxid);}}