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

1. ZK集群架构设计：

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是通过内部选举确定的。

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

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

3. ZK特性：

• 顺序一致性：客户端发出的更新操作命令， 严格地按照其发起的顺序在Zookeeper中执行。 Zookeeper的所有写操作都通过主机点执行，从节点做复制同步操作，这样所有节点的更新顺序都和主节点相同。 详情可查阅FollowerRequestProcessor->CommitProcessor.processRequest() 采用LinkedList存储请求
• 实时性：ZooKeeper 保证客户端在一定的时间间隔内获得最新数据结果。比如客户端通过Watch机制监听不同的节点， 只要发生变化， 都能实时获取信息变化。
• 原子性：领导者在同步数据时会保证事务性，一次数据的更新操作，要么都成功，要么都失败， 没有其他的状态。

2. CAP定理

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中的文件系统结构

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的数据是存储在哪里呢？ 支持哪些存储方式？

数据存储方式分为三类：

1. 内存数据 查看org.apache.zookeeper.server.DataTree与DataNode源码 结合ZK节点来讲解， node和tree的关联。 查看ZKDatabase源码 在内存数据库中，存储了整棵树的内容，包括所有的节点路径、节点数据、ACL信息，Zookeeper会定时将这这些数据存储到磁盘上。 内存数据结构分为三类： DataTree是内存数据存储的核心 DataNode是数据存储的最小单元，内部主要保存数据内容、ACL列表、节点状态信息 ZKDatabase是ZK的内存数据库，管理Zookeeper的所有会话、DataTree存储和事务日志。
2. 事务日志 查看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
3. 数据快照（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创作分享， 欢迎关注， 谢谢