深入剖析Zookeeper原理(一)整体设计
1.ZK集群架构设计与特性1. ZK集群架构设计:ZK主要分为三种角色:演示查看ZK的角色状态, 命令: bin/zkServer.sh status角色的主要职责与作用?Leader(领导者):一个Zookeeper集群同一时间只会有一个实际工作的Leader,它会发起并维护与各Follwer及Observer间的心跳。所有的写操作必须要通过Leader完成再由Leader将写操作广播给其它服务
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的数据是存储在哪里呢? 支持哪些存储方式?
数据存储方式分为三类:
-
内存数据
查看org.apache.zookeeper.server.DataTree与DataNode源码
结合ZK节点来讲解, node和tree的关联。
查看ZKDatabase源码
在内存数据库中,存储了整棵树的内容,包括所有的节点路径、节点数据、ACL信息,Zookeeper会定时将这这些数据存储到磁盘上。
内存数据结构分为三类:
- DataTree是内存数据存储的核心
- DataNode是数据存储的最小单元,内部主要保存数据内容、ACL列表、节点状态信息
- 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.300000005ZK集群会有一个专门的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
更多推荐
所有评论(0)