深入剖析Zookeeper原理（一）整体设计

最新推荐文章于 2022-09-15 19:46:30 发布

麦神-mirson

最新推荐文章于 2022-09-15 19:46:30 发布

阅读量3.2w

点赞数 1

分类专栏：分布式存储架构设计

本文链接：https://blog.csdn.net/hxx688/article/details/119549488

版权

架构设计同时被 2 个专栏收录

32 篇文章 3 订阅

订阅专栏

分布式存储

11 篇文章 4 订阅

订阅专栏

1. ZK集群架构设计与特性

1. ZK集群架构设计：

file

ZK主要分为三种角色：

Leader（领导者）：一个Zookeeper集群同一时间只会有一个实际工作的Leader，它会发起并维护与各Follwer及Observer间的心跳。所有的写操作必须要通过Leader完成再由Leader将写操作广播给其它服务器。
Follower（跟随者）：一个Zookeeper集群可能同时存在多个Follower，它会响应Leader的心跳。Follower可以处理客户端的读请求，但写请求转发给Leader处理，并且负责参与新 leader的选举、响应 leader 的提议。
Observer（观察者）：角色与Follower类似，但是无投票权，不参加选举，也不响应提议。

其次是 Observer不需要将事务持久化到磁盘，一旦 Observer被重启，需要从 leader 重新同步整个名字空间。Observer可以接收客户端连接，将写请求转发给leader，设计Observer的目的是为了扩展系统，提升读取速度。

2. ZK的网络架构：

Zookeeper的工作集群可以简单划分为Leader和follower，后续章节会讲解Leader是通过内部选举确定的。

file

Leader和各个follower是互相通信的，对于zk系统的数据都是保存在内存里面的，为防止数据丢失，也会备份一份在磁盘上。对于每个zk节点而言，可以看做每个zk节点的命名空间是一样的，也就是有同样的数据。

如果Leader挂了，zk集群会重新选举，在毫秒级别就会重新选举出一个Leaer。集群中除非有一半以上的zk节点挂了，整个ZK集群才不可用。

3. ZK特性：

顺序一致性：客户端发出的更新操作命令，严格地按照其发起的顺序在Zookeeper中执行。

Zookeeper的所有写操作都通过主机点执行，从节点做复制同步操作，这样所有节点的更新顺序都和主节点相同。

详情可查阅FollowerRequestProcessor->CommitProcessor.processRequest()

采用LinkedList存储请求
实时性：ZooKeeper 保证客户端在一定的时间间隔内获得最新数据结果。比如客户端通过Watch机制监听不同的节点，只要发生变化，都能实时获取信息变化。
原子性：领导者在同步数据时会保证事务性，一次数据的更新操作，要么都成功，要么都失败，没有其他的状态。

2. CAP定理

file

CAP定理，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性）这三个基本需求，最多只能同时满足其中的2个。

Consistency（一致性）：

在分布式环境中，一致性是指数据在多个副本之间是否能够保持数据一致的特性。例如一个将数据副本分布在不同分布式节点上的系统来说，如果对第一个节点的数据进行了更新操作并且更新成功后，其他节点上的数据也应该得到更新，并且所有用户都可以读取到其最新的值，那么这样的系统就被认为具有强一致性（或严格的一致性）。

Availability（可用性）：

可用性是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。有效的时间是指，对于用户的一个操作请求，系统必须能够在指定的时间（即响应时间）内返回处理结果，如果超过了这个时间范围，那么系统就被认为是不可用的。

返回结果是可用性的另一个非常重要的指标，它要求系统在完成对用户请求的处理后，返回一个正常的响应结果。正常的响应结果通常能够明确的反映出对请求的处理结果，即成功或失败，而并非一个不明确的结果。

Partition Tolerance（分区容错性）：

分区容错性约束了一个分布式系统需要具有如下特性：分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。

什么是网络分区？它是指在分布式系统中，不同的节点分布在不同的网络（比如机房或异地网络等）中，由于一些特殊的原因（比如DNS，路由等故障）导致这些子网络之间出现网络不连通的状况，但各个子网络的内部网络是正常的，从而导致整个系统的网络环境被切分成了若干个孤立的区域，形成了不同的网络分区。

由于一个分布式系统无法同时满足上面的三个需求，而只能满足其中的两项，因此在依据CAP定理应用的时候，需要根据业务需求权衡考虑，抛弃其中的一项。那Zookeeper是如何运用的？它又遵循了哪两种特性？

ZK在CAP定理中，保证的是CP特性。

ZK为什么不能满足可用性呢？

作为ZK的核心实现算法Zab，就是解决了分布式系统下数据如何在多个服务之间保持同步问题的。如果ZK下所有节点都断开了，或者集群中出现网络分割的故障，ZK会将他们从自己管理范围内剔除出去，外界就不能访问到这个节点，即便这些节点本身是健康的，可以正常提供服务。

在剔除故障节点的这段时间内，ZK可能会丢弃一些请求，消费者程序需要重新请求才能获得结果。

ZK在什么情况下是不能保证可用呢？

之前我们讲过，ZK的所有写请求都必须经由leader节点处理，所以ZK在进行leader选举时集群都是不可用的。

客户端可以考虑加入重试机制来做补偿

3. ZK数据结构与存储

1. ZK数据结构模型

在Zookeeper当中，数据是如何存储呢，它有怎样的特点？其实ZK的数据结构类似linux中的文件系统结构

file

ZK命名空间中的每个节点路径都是唯一标识。命名空间是可以支持层级的。

ZNode节点属性：

[zk: localhost:2181(CONNECTED) 1] get /testNode
test
cZxid = 0x2
ctime = Fri Aug 06 22:28:23 CST 2020
mZxid = 0x2
mtime = Fri Aug 06 22:28:23 CST 2020
pZxid = 0x2
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 4
numChildren = 0

具体可以查看org.apache.zookeeper.data.Stat源码：

cZxid ：创建的事务标识。
ctime：创建的时间戳。
mZxid：修改的事务标识，每次修改操作（set）后都会更新mZxid和mtime。
mtime：修改的时间戳。
pZxid：直接子节点最后更新的事务标识，子节点有变化（创建create、修改set、删除delete，rmr）时，都会更新pZxid。
cversion ：直接子节点的版本号。当子节点有变化（创建create、修改set、删除delete，rmr）时，cversion 的值就会增加1。
dataVersion ：节点数据的版本号，每次对节点进行修改操作（set）后，dataVersion的值都会增加1（即使设置的是相同的数据）。
aclVersion ：节点ACL的版本号，每次节点的ACL进行变化时，aclVersion 的值就会增加1。
ephemeralOwner：当前节点是临时节点（ephemeral node ）时，这个ephemeralOwner的值是客户端持有的session id。
dataLength：节点存储的数据长度，单位为 B （字节）。
numChildren：直接子节点的个数。

2. ZK数据存储方式

上面讲过ZK的数据结构模型，实质上是类似树形的结构，那ZK的数据是存储在哪里呢？ 支持哪些存储方式？

数据存储方式分为三类：

内存数据

查看org.apache.zookeeper.server.DataTree与DataNode源码

结合ZK节点来讲解， node和tree的关联。

查看ZKDatabase源码

在内存数据库中，存储了整棵树的内容，包括所有的节点路径、节点数据、ACL信息，Zookeeper会定时将这这些数据存储到磁盘上。

内存数据结构分为三类：
1. DataTree是内存数据存储的核心
2. DataNode是数据存储的最小单元，内部主要保存数据内容、ACL列表、节点状态信息
3. ZKDatabase是ZK的内存数据库，管理Zookeeper的所有会话、DataTree存储和事务日志。

事务日志

查看ZK数据存储目录， /data/zookeeper/version-2

-rw-r–r--. 1 root root 67108880 Mar 24 11:17 log.100000001
-rw-r–r--. 1 root root 67108880 Mar 25 01:23 log.1000001c4
-rw-r–r--. 1 root root 67108880 Mar 25 01:45 log.300000001
-rw-r–r--. 1 root root 67108880 Mar 26 12:44 log.300000005

ZK集群会有一个专门的dataDir目录，用来存储事务日志文件。该目录确定了当前ZK使用的事务日志格式版本号，当下次某个ZK版本对事务日志格式进行变更时，此目录也会变更，并在目录下生成一系列文件大小一致(64MB)的文件。

进入ZK目录/usr/local/zookeeper-3.4.14，选取最新的日志文件，再执行：

java -classpath .:./lib/slf4j-api-1.7.25.jar:./zookeeper-3.4.14.jar org.apache.zookeeper.server.LogFormatter /data/zookeeper/version-2/log.100000001 > log1.log

产生的日志内容：

8/9/21 8:55:19 PM EDT session 0x20003a778cc0012 cxid 0xa9 zxid 0x1000001bc delete '/lock-namespace/shared_lock/order/W-0000000016

8/9/21 8:55:29 PM EDT session 0x20003a778cc0012 cxid 0xb0 zxid 0x1000001bd delete '/lock-namespace/shared_lock/order/W-0000000017

8/9/21 9:46:18 PM EDT session 0x20003a778cc0012 cxid 0xb1 zxid 0x1000001be create '/lock-namespace/shared_lock/order/W-0000000018,#3139322e3136382e3132332e313033,v{s{31,s{'world,'anyone}}},T,19

8/9/21 9:46:38 PM EDT session 0x20003a778cc0012 cxid 0xb4 zxid 0x1000001bf delete '/lock-namespace/shared_lock/order/W-0000000018

数据快照（snapshot）

数据快照用来记录Zookeeper服务器上某一时刻的全量内存数据内容，并将其写入指定的磁盘文件中。

Zookeeper在进行若干次事务日志记录后，将内存数据库的全量数据Dump到本地文件中，这个就是数据快照。

快照查看命令：
```
java -classpath .:./lib/slf4j-api-1.7.25.jar:./zookeeper-3.4.14.jar org.apache.zookeeper.server.SnapshotFormatter /data/zookeeper/version-2/snapshot.100000000 > snap1.log
```
查看源码： SyncRequestProcessor.run() -> zks.takeSnapshot()

在新增log（txn log）文件数量达到snapCount/2 + Random.nextInt(snapCount/2)时，将会对zkDatabase(内存数据库)进行snapshot。

本文由mirson创作分享，如需进一步交流，请加QQ群：19310171或访问www.softart.cn

麦神-mirson

关注

1
点赞
踩
5

收藏

觉得还不错? 一键收藏
打赏
0
评论
深入剖析Zookeeper原理（一）整体设计

1. ZK集群架构设计与特性1. ZK集群架构设计：ZK主要分为三种角色：演示查看ZK的角色状态，命令： bin/zkServer.sh status角色的主要职责与作用？Leader（领导者）：一个Zookeeper集群同一时间只会有一个实际工作的Leader，它会发起并维护与各Follwer及Observer间的心跳。所有的写操作必须要通过Leader完成再由Leader将写操作广播给其它服务器。Follower（跟随者）：一个Zookeeper集群可能同时存在多个Follow
复制链接

扫一扫