分布式组件 ZooKeeper 介绍术语概述以及集群搭建篇

Posted 2023-03-30 vnjohn

• • 前言
  • 服务模型
  • 术语概述
  • • namespace
    • node
    • myid
    • Zxid
    • 选举状态
    • 特征
  • 安装及使用
  • • install
    • 核心配置文件参数详解
    • 使用
  • 总结

前言

ZooKeeper 是分布式应用程序的分布式开源协调服务；它公开了一组简单的原语，分布式应用程序可以基于这些原语来实现更高级别的同步、配置维护以及组和命名服务；数据模型是以熟悉的文件系统目录结构为导向的

ZooKeeper 官网：https://zookeeper.apache.org/doc/current/zookeeperOver.html

1. ZooKeeper very simple，通过共享的命名空间相互协调，该命名空间的组织类似于标准文件系统；ZK 数据保存在内存中，这意味着 ZK 可以实现高吞吐量和低延迟
2. ZooKeeper 可以用来做复制->数据同步的，Leader 服务节点用来处理 write 写请求，其他 follower、 observer 服务节点用来处理 read 请求，它们接收到写请求时都是转交给 Leader 节点处理的
3. ZooKeeper 速度很快，ZooKeeper 应用程序在数千台机器上运行，它在更常见的情况读取比写入表现最佳，比率约为 10:1，读取多于写入的应用程序中具有特别高的性能，因为写入涉及到需要同步所有服务器状态（读取多于写入通常是协调服务的情况）

①跟随者的失败和恢复、②不同 follower 的故障和恢复、③领导者的失败、④两个 follower 的故障和恢复、⑤另一个领导者的失败

摘自官网的这张图中，有一些重要的观察结果。首先，如果跟随者失败并快速恢复，那么即使出现故障，ZooKeeper 也能够维持高吞吐量。但也许更重要的是，领导者选举算法允许系统足够快地恢复以防止吞吐量大幅下降。在我们的观察中，ZooKeeper 花费不到 200 毫秒的时间来选举一个新的领导者。其次，随着追随者的恢复，一旦他们开始处理请求，ZooKeeper 能够再次提高吞吐量

服务模型

在 ZK 集群正常运作时，由客户端发起写请求，若请求的节点为 Follow 节点，那么它还会转发给到 Leader，由 Leader 节点去完成这部分写操作；若为读请求，在 Follow 节点这一侧直接读取即可.

既然是集群了，总归是会有网络不稳定或资源不足的情况导致节点宕机，在故障恢复的这一阶段，其他请求的服务都是 不可用状态，而 ZK 作为分布式协调服务组件，它必然会有可靠的方式去保证集群可用态

在 ZK 内部基于 Paxos 一致性算法，通过 ZAB(ZooKeeper Atomic Broadcast)->ZK 原子广播协议来恢复集群为可用状态；它有两种基本模式，如下：
1、崩溃恢复，Leader 出现网络中断、崩溃重启等异常情况下，ZAB 协议就会进行到恢复模式，来重新选举一个新的 Leader 服务来处理事务请求，当新的 Leader 服务器选择出来以后，并且和过半以上的机器进行了状态同步以后，恢复模式就结束了。在选举时，会有如下过程：3888 端口形成 一对一 通信、任何人投票，都会触发准 Leader 发起自己的投票、推选机制：先比较节点内部的 Zxid，若 Zxid 相同，就选取那个 myid 值最大的节点作为 Leader

2、消息广播，消息广播使用的是一个原子广播协议，整体的过程可以看作是一个二阶段提交的过程.
第一阶段，Leader 机器会将事务消息生成对应的 proposal(提案)广播，并且会生成一个单调递增的 ID，作为事务的 ID(Zxid)，由于 ZAB 协议需要保证事务严格的上下顺序性，所以会严格按照 Zxid 的先后来处理对应的消息；在消息广播发起后，Leader 会为每一个 Follower 服务器分配一个单独的队列，然后将需要广播出去的事务 Proposal 依次存放进这个 FIFO 队列中，每个 Follower 机器收到事务消息后，会按照事务日志的方式写入，成功反馈给 Leader 服务器 Ack 响应，当收到半数以上的 Ack 响应后，Leader 就会发起第二阶段的 Commit 消息给所有的 Follower 机器，并且这个时候 Leader 也会和 Follower 一样进行本地事务的提交操作，完成整个消息的传递和提交

推荐一篇文章，使用总统选举的例子，来简要描述 ZK 服务中的一些概念模型，Zookeeper全解析——Paxos作为灵魂

术语概述

namespace

ZooKeeper 提供的命名空间很像标准文件系统中的命名空间，名称是由斜杠 (/) 分隔开的一系列路径元素，ZooKeeper 命名空间中的每个节点都有路径去标识，每个节点最大存储数据大小为 1MB

node

ZooKeeper 命名空间中的每个节点都可以拥有与其关联的数据以及子节点，使用术语 znode 来明确 ZooKeeper 的数据节点

节点存在以下几种类型

1. 持久化节点：默认 create /path data，就是持久化节点
2. 临时节点：create -e(ephemeral)，通过它来创建客户端节点的 session，处于活动状态，znode 存在；当会话结束以后，znode 就会被删除
3. 序列化节点：create -s，防止多个客户端同时设置同一个节点，若为同一个节点时，通过 -s 创建完的节点会按序列增长 00000000

节点存在以下的特征及使用：

1. 统一的配置管理，每个 node 节点最多可存储 1M 大小
2. 分组管理，基于 path 目录树结构
3. 统一命名，通过 sequence 来保证节点唯一
4. 会话状态下的同步、分布式锁，通过临时节点来保证，锁依托于一个父节点且它具备 -s 系列化形式，代表父节点下可以同时拥有多把锁，以一个队列式方式存储事务的锁
5. 大数据场景下，通常用分布式锁来进行选主，谁抢到这把锁那么谁就是主节点

myid

Server Id：服务器 id，它是每个服务节点的唯一标识

比如有三台服务节点，编号分别是 1、2、3，编号越大的服务权重就越大，在初始化启动时就是根据服务器 id 来进行比较的，较小的编号会变更选票偏向于编号大的，当对应的编号获得集群中过半数选票，那么此编号标识的服务就是 Leader

Zxid

ZooKeeper transaction：事务id

服务中存放的事务 id 越大代表它的数据越新，即代表它的权重就越大，在重新选举时通过 Zxid 值比较，谁大谁当主

选举状态

Looking：竞选状态
Following：随从状态，同步 Leader 状态，参与选票
Observing：观察状态，同步 Leader 状态，不参与选票
Leading：领导者状态

特征

ZooKeeper 非常快速且非常简单，但是，由于它的目标是成为构建更复杂服务（例如同步）的基础，因此它提供了一组保证，如下：

1. 顺序一致性：来自客户端的更新将按发送的顺序应用
2. 原子性：更新要么成功要么失败，没有部分结果
3. 统一视图：无论连接到哪个服务器，客户端都将看到相同的服务视图。即使客户端故障转移到具有相同会话的不同服务器，客户端也永远不会看到系统的旧视图
4. 可靠性：应用更新后，它将从那时起持续存在，直到客户端覆盖更新
5. 及时性：系统的客户视图保证在特定时间范围内是最新的

安装及使用

基于该文章搭建好多台虚拟机节点：Mac M1 搭建虚拟机节点集群过程及软件分享

前置环境要求：Jdk 1.8，之前在搭建 Nacos 集群有具体描述：Nacos 介绍及搭建集群、相关组件

那么接下来就是如何搭建好一个 ZooKeeper 集群，准备好四台虚拟机节点，172.16.249.10-172.16.249.13（node1-node4）

zookeeper-tar.gz 下载：https://archive.apache.org/dist/zookeeper/zookeeper-3.4.6/

install

前置工作，先为每台机器节点配置域名，实现节点之间通过域名方式绑定

1. vim /etc/hosts

172.16.249.10 node1
172.16.249.11 node2
172.16.249.12 node3
172.16.249.13 node4

2. 刷新域名 IP 配置：iptables -F

上传 zookeeper-release-3.4.6.tar.gz 文件到服务器中

1、解压 tar.gz：tar xf zookeeper-3.4.6.tar.gz
2、将文件拷贝到指定目录下：mv -p zookeeper-3.4.6 /opt/vnjohn/zk
3、备份配置文件：cd conf/ && cp zoo_sample.cfg zoo.cfg
4、调整 zoo.cfg 配置文件

# 指定数据目录
dataDir=/var/vnjohn/zk
# 绑定 Server Id、节点 | 端口 关系
server.1=node1:2888:3888
server.2=node2:2888:3888
server.3=node3:2888:3888
server.4=node4:2888:3888

5、创建目录&设置节点的 Servcer Id 值，每个节点要设置的值不一样

# node1
mkdir -p /var/vnjohn/zk && touch /var/vnjohn/zk/myid && echo 1 > /var/vnjohn/zk/myid
# node2
mkdir -p /var/vnjohn/zk && touch /var/vnjohn/zk/myid && echo 2 > /var/vnjohn/zk/myid
# node3 
mkdir -p /var/vnjohn/zk && touch /var/vnjohn/zk/myid && echo 3 > /var/vnjohn/zk/myid
# node4
mkdir -p /var/vnjohn/zk && touch /var/vnjohn/zk/myid && echo 4 > /var/vnjohn/zk/myid

6、由于每台节点的配置信息基本上都是一致的，除了 myid 文件内容需要保持不同而已，所以直接通过SFTP 方式传递到其他节点->node2~node4，目录保持和 node1 一样，再根据第 5 点设置 Server Id 值即可.
7、调整 /etc/profile 配置文件内容，追加内容如下：

ZOOKEEPER_HOME=/opt/vnjohn/zk
export PATH=$PATH:$ZOOKEEPER_HOME/bin

刷新配置文件：source /etc/profile
若配置文件修改出现问题，导致所有命令都不生效了，运行✅：export PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin 后，再重新调整配置

8、启动 ZK，默认是后台运行的，先通过前台运行观察控制台打印的日志【zkServer.sh start-foreground】，如下：

刚启动的节点目前还是一个竞选 LOOKING 状态，通过 zkServer.sh status 命令可以查看 ZK 节点的状态，输出的日志内容告知它并未在运行【其实也说明它目前所在的选举状态：LOOKING】

[root@localhost ~]# zkServer.sh status
JMX enabled by default
Using config: /opt/vnjohn/zk/bin/../conf/zoo.cfg
Error contacting service. It is probably not running.

当 node2、node3 起来以后，node2 角色是 follow，而 node-3 角色必然就是 leader，初始化启动主要通过 myid【Service id】最大值对比，最大值的那个节点作为 Leader 节点，观察 node3 节点最后的输出日志

选举完成、同步数据给 Follower、收到 ack 响应
若 node4 此时再启动，那么它仍然会变为 node3 跟随者，随即 Leader 也会给它同步一份最新的数据样本

9、查看 node4->2888/3888 端口 TCP 连接信息

从图中可以观察到一些信息，node4 与 node1、2、3 的 3888 端口建立了连接，它们之间的通信是为了选举投票用的；但唯独与 node3 节点 2888 端口建立了连接，它的作用是：当 node4->follower 接到 write 写请求时，通过该端口转发数据包给 Leader 去处理

核心配置文件参数详解

# leader 和 follow 每个连接心跳的毫秒数
tickTime=2000
# 当有新的 follow 节点追随 leader 时，可以被允许 10*2000 20秒时间等待连接
initLimit=10
# leader 同步数据给 follow 时，5*2000 10秒没有获得回复也认为 follow 有问题
syncLimit=5
# 持久化目录
dataDir=/var/vnjohn/zookeeper
# 客户端连接的端口号
clientPort=2181
# 允许客户端最大连接数量，可以调大
# maxClientCnxns=60
# 3888 用处：当主挂了以后，这个时候就需要去投票选举，用这个端口
# 2888 用处：当主选好以后，就用这个端口 Leader 节点做通信 
server.1=node1:2888:3888
server.2=node2:2888:3888
server.3=node3:2888:3888
server.4=node4:2888:3888

使用

ZK 集群搭建好了，现在我们就可以基于它自带的客户端进行连接，去进行一些实际的命令操作！

1、进入控制台，输入：zkCli.sh 后回车即可
2、创建持久节点：create /vnjohn “”

创建一个 ooxx 的空内容节点，如果后面不写内容的话就不会进行创建，比如：create /vnjohn

3、创建临时节点：create /vnjohn/ephemeral -e

若我当前这个客户端连接关闭后，这个节点就会消失不见！

4、创建序列节点：create /vnjohn/sequence:1:1 -s “sequence” 10

防止并行时创建同样的节点从而覆盖掉，ZK 帮忙做了数据隔离

5、获取节点信息：get /vnjohn，获取到 vnjohn 创建时给的内容，同时对以下的参数进行描述：

""  									# 节点内容
cZxid = 0x200000002						# 创建节点时分配的事务 ID
ctime = Sat Mar 18 12:27:56 CST 2023	# 创建节点的时间
mZxid = 0x200000002						# 修改节点时分配的事务 ID
mtime = Sat Mar 18 12:27:56 CST 2023	# 修改节点的时间
pZxid = 0x200000005						# 当前节点下的最后一个子节点事务 ID，没有子节点就是当前节点的事务 ID
cversion = 2
dataVersion = 0
aclVersion = 0			
# 临时拥有者，只有创建临时节点时才会有值，这个值是客户端连接 ZK 时分配的 SESSION_ID
# 如果这个 SESSION 关闭了，这个节点就会消失 
# SESSION 在所有 zookeeper 节点下是都可以被看到的
ephemeralOwner = 0x0 								
dataLength = 2
# 子节点数量，/vnjohn 下目前存在两个子节点
numChildren = 2											

6、查询父节点下有多少个子节点：ls /

[zk: localhost:2181(CONNECTED) 24] ls /
[vnjohn, zookeeper]

连接 ZK 和关闭 ZK 都会消耗一个事务 ID

总结

该篇文，对 ZooKeeper 服务模型以及它的一些特性作了简要的描述，同时，介绍了 ZooKeeper 中一些面试中常常问到的术语，比如：myid、Zxid、选举状态等；为大家准备了在 Linux 中如何搭建好一个 ZK 集群，从日志内容分析出它与上下文之间的关系，对核心配置文件 zoo.cfg 参数作了介绍，最后对一些常见的 ZK 命令操作作了演示，当然，还有更多的特性，比如：分布式锁、Watch 机制！

推荐给大家 Raft 算法演变过程的网站，用动画的方式生动演练了选举主的过程->Raft Distributed Consensus

如果觉得博文不错，关注我 vnjohn，后续会有更多实战、源码、架构干货分享！
大家的「关注❤️ + 点赞👍 + 收藏⭐」就是我创作的最大动力！谢谢大家的支持，我们下文见！

[高级]Zookeeper介绍——Zookeeper概述

在中介绍过，随着网站的不断发展，逐渐从集中式演变到分布式。但是，在分布式系统中存在着很多数据一致性的问题。那么，有没有什么系统或者组件能够帮助我们解决这些一致性问题呢？本文将简单介绍一个分布式服务协调组件——Zookeeper。

什么是Zookeeper

Zookeeper是一个开放源码的分布式服务协调组件，是Google Chubby的开源实现。是一个高性能的分布式数据一致性解决方案。他将那些复杂的、容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集，并提供一系列简单易用的接口给用户使用。

Zookeeper提供了哪些特性

他解决的分布式数据一致性问题，提供了顺序一致性、原子性、单一视图、可靠性、实时性等。

顺序一致性：客户端的更新顺序与他们被发送的顺序相一致；

原子性：更新操作要么全部成功，要么全部失败；

单一试图：无论客户端连接到哪一个服务器，都可以看到相同的ZooKeeper视图；

可靠性：一旦一个更新操作被应用，那么在客户端再次更新它之前，其值将不会被改变；

实时性：在特定的一段时间内，系统的任何变更都将被客户端检测到；

Zookeeper工作过程

上图中，一个Zookeeper集群中有五台机器，在整个集群刚刚启动的时候，会进行Leader选举，当Leader确定之后，其他机器自动成为Follower，并和Leader建立长连接，用于数据同步和请求转发等。当有客户端机器的写请求落到follower机器上的时候，follower机器会把请求转发给Leader，由Leader处理该请求，比如数据的写操作，在请求处理完之后再把数据同步给所有的follower。

CAP理论

在分布式领域，有一个著名的理论——。CAP理论的核心观点是任何软件系统都无法同时满足一致性、可用性以及分区容错性。

值得一提的是，作为一个分布式系统，分区容错性是一个必须要考虑的关键点。一个分布式系统一旦丧失了分区容错性，也就表示放弃了扩展性。因为在分布式系统中，网络故障是经常出现的，一旦出现在这种问题就会导致整个系统不可用是绝对不能容忍的。所以，大部分分布式系统都会在保证分区容错性的前提下在一致性和可用性之间做权衡。

在CAP这三个关键的性质中，同时满足CA两点的是著名的数据库中ACID、同时满足AP两点的是注明的。

Zookeeper和CAP的关系

上面介绍过，没有任何一个分布式系统可以同时满足CAP，Zookeeper一般以集群的形式对外提供服务，那么Zookeeper在CAP中是如何取舍的呢？

ZooKeeper是个CP（一致性+分区容错性）的，即任何时刻对ZooKeeper的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性;但是它不能保证每次服务请求的可用性(注：也就是在极端环境下，ZooKeeper可能会丢弃一些请求，消费者程序需要重新请求才能获得结果)。但是别忘了，ZooKeeper是分布式协调服务，它的 职责是保证数据(注：配置数据，状态数据)在其管辖下的所有服务之间保持同步、一致;所以就不难理解为什么ZooKeeper被设计成CP而不是AP特性的了，如果是AP的，那么将会带来恐怖的后果(注：ZooKeeper就像交叉路口的信号灯一样，你能想象在交通要道突然信号灯失灵的情况吗?)。而且， 作为ZooKeeper的核心实现算法 Zab，就是解决了分布式系统下数据如何在多个服务之间保持同步问题的。

如果 ZooKeeper下所有节点都断开了，或者集群中出现了网络分割的故障(注：由于交换机故障导致交换机底下的子网间不能互访);那么ZooKeeper 会将它们都从自己管理范围中剔除出去，外界就不能访问到这些节点了，即便这些节点本身是“健康”的，可以正常提供服务的;所以导致到达这些节点的服务请求 被丢失了。