一、zookeeper 概述
中文教程:https://www.docs4dev.com/docs/zh/zookeeper/r3.5.6/reference/zookeeperOver.html
1.1 概述
ZooKeeper 是⼀种分布式协调服务,⽤于管理⼤型主机。在分布式环境中协调和管理服务是 ⼀个复杂的过程。ZooKeeper 通过其简单的架构和 API 解决了这个问题。ZooKeeper 允许开 发⼈员专注于核⼼应⽤程序逻辑,⽽不必担⼼应⽤程序的分布式特性。
1.2 使用场景
- 分布式协调组讲
分布式服务下需要对数据状态进行统计管理,比如用户的登录情况。
- 分布式锁
zk在实现分布式锁上,可以做到强⼀致性,关于分布式锁相关的知识,在之后的ZAB协议中介绍。
- 无状态实现
二、zookeeper 服务配置与使用
2.1 zookeeper 服务搭建
2.1.1 安装包部署
官方网址:https://zookeeper.apache.org/releases.html
详细安装过程大家可以自行百度
2.1.2 Docker 部署
docker run -d \
-e TZ="Asia/Shanghai" \
-p 2181:2181 \
-v /Users/rion/Data/DockerVolumesData/zookeeper/zookeeper01/data:/data \
-v /Users/rion/Data/DockerVolumesData/zookeeper/zookeeper01/conf:/conf/ \
-v /Users/rion/Data/DockerVolumesData/zookeeper/zookeeper01/log:/datalog/ \
--name zookeeper01 zookeeper
参数:
-e:表示添加环境变量
-p:设置宿主机和容器内部端口的映射
-v:表示挂载目录
/data : zookeeper 的数据目录
/conf :zookeeper 的配置文件目录
/datalog : zookeeper 的日志目录
2.2 配置文件
# zookeeper时间配置中的基本单位 (毫秒)
tickTime=2000
# 允许follower初始化连接到leader最⼤时⻓,它表示tickTime时间倍数
即:initLimit*tickTime
initLimit=10
# 允许follower与leader数据同步最⼤时⻓,它表示tickTime时间倍数
syncLimit=5
#zookeper 数据存储⽬录及⽇志保存⽬录(如果没有指明dataLogDir,则⽇志也保存在这个
⽂件中)
dataDir=/tmp/zookeeper
#对客户端提供的端⼝号
clientPort=2181
#单个客户端与zookeeper最⼤并发连接数
maxClientCnxns=60
# 保存的数据快照数量,之外的将会被清除
autopurge.snapRetainCount=3
#⾃动触发清除任务时间间隔,⼩时为单位。默认为0,表示不⾃动清除。
autopurge.purgeInterval=1
# zookeeper Web UI
admin.enableServer=true
# 它表示ZooKeeper运行在单个服务器上,没有复制或分布式的特性。
# 当standaloneEnabled设置为true时,ZooKeeper将以Standalone模式启动,这意味着它将在单个服务器上运行,
# 并且没有复制或高可用性的功能。这对于测试、开发或单服务器环境可能是合适的。
# 当standaloneEnabled设置为false时,ZooKeeper将以分布式模式启动,可以在多个服务器上组成一个ZooKeeper集群。
# 在分布式模式下,ZooKeeper可以实现数据的复制和高可用性,以提供更好的容错和可扩展性。
standaloneEnabled=true
2.3 服务启动与停止
- 先进入docker 容器中
docker exec -it <containerd_name> | <containerd_id> bash
- 在bin目录下存放则服务启动的脚本
zkCli.sh :连接服务端的脚本
zkServer.sh:服务端服务控制脚本
zkServer.sh start /conf/zoo.cfg # 默认会使用该文件,不存在会提示
zkServer.sh status # 查看服务器状态
zkServer.sh stop
三、zookeeper 数据模型
3.1 zookeeper 如何保存数据结构
zk中的数据是保存在节点上的,节点就是znode,多个znode之间构成⼀颗树的⽬录结构。
ZooKeeper 提供的名称空间与标准文件系统的名称空间非常相似。名称是由斜杠(/)分隔的一系列路径元素。 ZooKeeper 名称空间中的每个节点都由路径标识。
节点路径可以理解为key,同时还可以给key设置value。
3.2 znode 结构
zookeeper 中的node包含一下四个部分:
-
data:保存数据
-
acl:权限,定义了什么样的⽤户能够操作这个节点,且能够进⾏怎样的操作。
-
- c: create 创建权限,允许在该节点下创建⼦节点
- w:write 更新权限,允许更新该节点的数据
- r:read 读取权限,允许读取该节点的内容以及⼦节点的列表信息
- d:delete 删除权限,允许删除该节点的⼦节点
- a:admin 管理者权限,允许对该节点进⾏acl权限设置 /动物/猫 /汽⻋/宝⻢ 1 2
-
stat:描述当前znode的元数据(节点的信息),
get -s <nodeName>
-
child:当前节点的⼦节点
3.3 znode 类型
- 持久节点: 创建出的节点,在会话结束后依然存在。保存数据
- 持久序号节点: 创建出的节点,根据先后顺序,会在节点之后带上⼀个数值,越后执⾏数 值越⼤,适⽤于分布式锁的应⽤场景- 单调递增 , 就类似于数据库中加锁时使用version字段,逐步增加version字段的值。
- 临时节点: 临时节点是在会话结束后,⾃动被删除的,通过这个特性,zk可以实现服务注册与发现的 效果。那么临时节点是如何维持⼼跳呢?
- 临时序号节点:跟持久序号节点相同,适⽤于临时的分布式锁。
- Container节点(3.5.3版本新增):Container容器节点,当容器中没有任何⼦节点,该 容器节点会被zk定期删除(60s)。
- TTL节点:可以指定节点的到期时间,到期后被zk定时删除。只能通过系统配置 zookeeper.extendedTypesEnabled=true 开启
3.4 数据持久化
zk的数据是运⾏在内存中,zk提供了两种持久化机制:
- 事务⽇志
zk把执⾏的命令以⽇志形式保存在dataLogDir指定的路径中的⽂件中(如果没有指定 dataLogDir,则按dataDir指定的路径)。
- 数据快照
zk会在⼀定的时间间隔内做⼀次内存数据的快照,把该时刻的内存数据保存在快照⽂件中。
zk通过两种形式的持久化,在恢复时先恢复快照⽂件中的数据到内存中,再⽤⽇志⽂件中的 数据做增量恢复,这样的恢复速度更快。
你会发现和redis的数据持久化有些类似。
四、zkCli 客户端
4.1 创建节点
create /t # 默认为持久化节点
create -s /t # 创建持久化序号节点,即有事务序号, 会在节点末尾添加序号
create -c /t # 容器节点
create -ttl # 有时限的节点,就像rediskey设置过期时间一样
create -e /t # 临时节点,当前会话存在时,该节点会存在,若会话关闭,则该节点会被删除
# 常被用于注册中心服务发现等
节点元数据信息
[zk xxx] get -s /t
cZxid: 创建节点的事务ID
mZxid:修改节点的事务ID
pZxid:添加和删除⼦节点的事务ID
ctime:节点创建的时间
mtime: 节点最近修改的时间
dataVersion: 节点内数据的版本,每更新⼀次数据,版本会+1
aclVersion: 此节点的权限版本
ephemeralOwner: 如果当前节点是临时节点,该值是当前节点所有者的session
id。如果节点不是临时节点,则该值为零。
dataLength: 节点内数据的⻓度
numChildren: 该节点的⼦节点个数
4.2 查询节点
- ls
ls /t # 默认显示当前节点下的一级子节点信息
ls -w /t # 监听⽬录,创建和删除⼦节点会收到通知。⼦节点中新增节点不会收到通知
ls -R /t # 递归显示该节点下的所有子节点
ls -w -R /t # 对于⼦节点中⼦节点的变化,但内容的变化不会收到通知
- get
get -s # 查询节点的元信息
get -w # w (watch) 监听节点的数据变化(一次性的)
get -w znode
一旦数据节点发送变化,会出发一个监听事件,type 表明了数据变化类型,如下:
WATCHER::
WatchedEvent state:SyncConnected type:NodeDataChanged path:/t
4.3 设置值
set <znode> <value>
# set /t "hello"
set -v <dataVersion> <znode> <data>
# set -v 2 /t 1234
# 只有当节点的版本号与提供的版本号匹配时,才会进行更新。如果版本号不匹配,操作将失败。
set <znode> -f <filePath>
# set /myNode -f /path/to/data.txt
需要注意的是,在使用set命令设置节点值时,节点路径和数据值都需要用引号括起来(除非路径或数据中不包含空格)。还要确保指定的节点路径在ZooKeeper中存在,否则会创建一个新的节点。
4.4 删除节点
delete <znode>
delete -v <dataVersion> <znode>
# 指定节点的版本进行删除,乐观锁。适用于读多写少的情况
deleteall <znode>
# 递归删除节点,即删除该节点下的所有子节点
4.5 权限
# 设置摘要
add auth digest root:123456
# 设置test节点值为abcd,并且需要进行认证,只有xiaowang:123456才可以进行增删写读的权限
create /test abcd auth:xiaowang:123456:cdwr
五、zookeeper 实现分布式锁
5.1 zookeeper 锁类型
5.1.1 读锁
⼤家都可以读,要想上读锁的前提:之前的锁没有写锁
5.1.2 写锁
只有得到写锁的才能写。要想上写锁的前提是,之前没有任何锁。
5.2 zookeeper 如何上读锁
-
创建⼀个临时序号节点,节点的数据是read,表示是读锁
-
获取当前zk中序号⽐⾃⼰⼩的所有节点
-
判断最⼩节点是否是读锁:
-
- 如果不是读锁的话,则上锁失败,为最⼩节点设置监听。阻塞等待,zk的watch机制 会当最⼩节点发⽣变化时通知当前节点,于是再执⾏第⼆步的流程
- 如果是读锁的话,则上锁成功
5.3 zookeeper 如何上写锁
-
创建⼀个临时序号节点,节点的数据是write,表示是 写锁
-
获取zk中所有的⼦节点
-
判断⾃⼰是否是最⼩的节点:
-
- 如果是,则上写锁成功
- 如果不是,说明前⾯还有锁,则上锁失败,监听最⼩的节点,如果最⼩节点有变化, 则回到第⼆步。
5.4 zookeeper 羊群效应
如果⽤上述的上锁⽅式,只要有节点发⽣变化,就会触发其他节点的监听事件,这样的话对 zk的压⼒⾮常⼤,——⽺群效应。可以调整成链式监听。解决这个问题。
六、zookeeper 集群实战
6.1 zookeeper 集群角色
zookeeper 集群有三种角色:
- Leader:处理集群的所有事务请求,集群中只有⼀个Leader。
- Follower:只能处理读请求,参与Leader选举。
- Observer:只能处理读请求,提升集群读的性能,但不能参与Leader选举。
6.2 集群搭建
本次搭建以视频内容为模版,使用docker 部署应该也是类似的
搭建4个节点,其中⼀个节点为Observer
(1)创建4个节点的myid,并设值
在/usr/local/zookeeper中创建以下四个⽂件
/usr/local/zookeeper/zkdata/zk1# echo 1 > myid
/usr/local/zookeeper/zkdata/zk2# echo 2 > myid
/usr/local/zookeeper/zkdata/zk3# echo 3 > myid
/usr/local/zookeeper/zkdata/zk4# echo 4 > myid
(2)编写4个zoo.cfg
# The number of milliseconds of each tick
tickTime=2000
# The number of ticks that the initial
# synchronization phase can take
initLimit=10
# The number of ticks that can pass between
# sending a request and getting an acknowledgement
syncLimit=5
# 修改对应的zk1 zk2 zk3 zk4
dataDir=/usr/local/zookeeper/zkdata/zk1
# 修改对应的端⼝ 2181 2182 2183 2184
clientPort=2181
# 2001为集群通信端⼝,3001为集群选举端⼝,observer表示不参与集群选举
server.1=172.16.253.54:2001:3001
server.2=172.16.253.54:2002:3002
server.3=172.16.253.54:2003:3003
server.4=172.16.253.54:2004:3004:observer
(3)启动4台Zookeeper
./bin/zkServer.sh status ./conf/zoo1.cfg
./bin/zkServer.sh status ./conf/zoo2.cfg
./bin/zkServer.sh status ./conf/zoo3.cfg
./bin/zkServer.sh status ./conf/zoo4.cfg
(4)zkCli 连接集群
./bin/zkCli.sh -server 172.16.253.54:2181,172.16.253.54:2182,172.16.253.54:2183
七、ZAB 协议
7.1 什么是ZAB协议
zookeeper作为⾮常重要的分布式协调组件,需要进⾏集群部署,集群中会以⼀主多从的形式 进⾏部署。zookeeper为了保证数据的⼀致性,使⽤了ZAB(Zookeeper Atomic Broadcast)协议,这个协议解决了Zookeeper的崩溃恢复和主从数据同步的问题。
7.2 zookeeper 定义四种节点状态
- Looking :选举状态。
- Following :Follower 节点(从节点)所处的状态。
- Leading :Leader 节点(主节点)所处状态。
- Observing:观察者节点所处的状态
7.3 集群上线的leader选举
Zookeeper集群中的节点在上线时,将会进⼊到Looking状态,也就是选举Leader的状态,这 个状态具体会发⽣什么?
- 第一轮
-
节点1
服务启动,生成一个一张自己的选票(1, 0)1表示节点myid,0 表示事务id
,因为刚启动服务,所以事务id为0 -
节点2
服务启动,生成一个一张自己的选票(2, 0)1表示节点myid,0 表示事务id
,因为刚启动服务,所以事务id为0 -
节点1
和节点2
都将自己的选票投给对方,即节点1
存在2张选票,节点2
存在2张选票 -
节点1
和节点2
选出最大的选票,选择方式:先比较zxid,再比较myid。 故节点1和节点2都选择了选票(2, 0)投入到投票箱中。 -
第一轮选票结束,此时选票箱中存在1张选票,由于当前存在三个节点,配置文件中(6.2小节)定义了
server.1=ip:port1:port2, server.2=xxx, server.3=xxx
,server.4=xxx
是observer节点,不参与选票。 -
在选举leader过程中,需要投票箱中的票数超过集群的半数才可以。所以会进行第二轮选举
- 第二轮
- 此时
节点1
中含有 1 张选票(2, 0),因为会保留它选择投到投票箱中的票。它会将最大的选票投递给对方,节点2
也是如此。所以都会把选票(2, 0) 投给对方 -
节点1
和节点2
此时再次进行对比,然后把选票(2, 0) 投递到投票箱中 - 此时投票箱中存在2张选票,大于集群数量的一半。故而
节点2
成为leader
,节点1
成为follower
节点3` 启动时发现已经存在`leader`,便会直接成为`follower
以上就是leader选举的全过程
7.4 崩溃恢复时的leader选举
Leader建⽴完后,Leader周期性地不断向Follower发送⼼跳(ping命令,没有内容的 socket)。
当Leader崩溃后,Follower发现socket通道已关闭,于是Follower开始进⼊到 Looking状态,重新回到7.3节中的Leader选举过程,此时集群不能对外提供服务。
7.5 主从服务器之间的数据同步
主要包含两阶段提交
- 第一阶段为节点将数据写入到本地数据文件中
- 第二阶段为节点将数据写入到内存中
7.6 zookeeper 的NIO和BIO
NIO
NIO (non-blocking IO)同步非阻塞IO
- ⽤于被客户端连接的2181端⼝,使⽤的是NIO模式与客户端建⽴连接
- 客户端开启Watch时,也使⽤NIO,等待Zookeeper服务器的回调
BIO
BIO(blocking IO)
- 集群在选举时,多个节点之间的投票通信端⼝,使⽤BIO进⾏通信。
详细解释nio&bio:https://blog.csdn.net/CSDN2497242041/article/details/120278946
八、CAP理论
8.1 CAP 定理
2000 年 7 ⽉,加州⼤学伯克利分校的 Eric Brewer 教授在 ACM PODC 会议上提出 CAP 猜 想。2年后,麻省理⼯学院的 Seth Gilbert 和 Nancy Lynch 从理论上证明了 CAP。之后, CAP 理论正式成为分布式计算领域的公认定理。
CAP 理论为:
⼀个分布式系统最多只能同时满⾜⼀致性(Consistency)、可⽤性 (Availability)和分区容错性(Partition tolerance)这三项中的两项。
⼀致性(Consistency) ⼀致性指 “all nodes see the same data at the same time”,即更新操作成功并返回客户端 完成后,所有节点在同⼀时间的数据完全⼀致。
可⽤性(Availability)可⽤性指“Reads and writes always succeed”,即服务⼀直可⽤,⽽且是正常响应时间。
分区容错性(Partition tolerance) 分区容错性指“the system continues to operate despite arbitrary message loss or failure of part of the system”,即分布式系统在遇到某节点或⽹络分区故障的时候,仍然能够对外 提供满⾜⼀致性或可⽤性的服务。——避免单点故障,就要进⾏冗余部署,冗余部署相当于 是服务的分区,这样的分区就具备了容错性。
8.2 CAP 权衡
通过 CAP 理论,我们知道⽆法同时满⾜⼀致性、可⽤性和分区容错性这三个特性,那要舍弃哪个呢?
对于多数⼤型互联⽹应⽤的场景,主机众多、部署分散,⽽且现在的集群规模越来越⼤,所 以节点故障、⽹络故障是常态,⽽且要保证服务可⽤性达到 N 个 9,即保证 P 和 A,舍弃 C(退⽽求其次保证最终⼀致性)。虽然某些地⽅会影响客户体验,但没达到造成⽤户流程的 严重程度。 对于涉及到钱财这样不能有⼀丝让步的场景,C 必须保证。⽹络发⽣故障宁可停⽌服务,这是 保证 CA,舍弃 P。貌似这⼏年国内银⾏业发⽣了不下 10 起事故,但影响⾯不⼤,报到也不 多,⼴⼤群众知道的少。还有⼀种是保证 CP,舍弃 A。例如⽹络故障是只读不写。
孰优孰略,没有定论,只能根据场景定夺,适合的才是最好的。
8.3 BASE 理论
eBay 的架构师 Dan Pritchett 源于对⼤规模分布式系统的实践总结,在 ACM 上发表⽂章提出 BASE 理论,BASE 理论是对 CAP 理论的延伸,核⼼思想是即使⽆法做到强⼀致性(Strong Consistency,CAP 的⼀致性就是强⼀致性),但应⽤可以采⽤适合的⽅式达到最终⼀致性 (Eventual Consitency)。
- 基本可⽤(Basically Available)
基本可⽤是指分布式系统在出现故障的时候,允许损失部分可⽤性,即保证核⼼可⽤。 电商⼤促时,为了应对访问量激增,部分⽤户可能会被引导到降级⻚⾯,服务层也可能只提 供降级服务。这就是损失部分可⽤性的体现。
- 软状态(Soft State)
软状态是指允许系统存在中间状态,⽽该中间状态不会影响系统整体可⽤性。分布式存储中 ⼀般⼀份数据⾄少会有三个副本,允许不同节点间副本同步的延时就是软状态的体现。mysql replication 的异步复制也是⼀种体现。
- 最终⼀致性(Eventual Consistency)
最终⼀致性是指系统中的所有数据副本经过⼀定时间后,最终能够达到⼀致的状态。弱⼀致 性和强⼀致性相反,最终⼀致性是弱⼀致性的⼀种特殊情况。
8.4 Zookeeper追求的⼀致性
Zookeeper在数据同步时,追求的并不是强⼀致性,⽽是顺序⼀致性(事务id的单调递增)。文章来源:https://www.toymoban.com/news/detail-479491.html
本文中内容依照千锋的视频课程:https://www.bilibili.com/video/BV1Ph411n7Ep/?spm_id_from=333.999.top_right_bar_window_custom_collection.content.click&vd_source=08c2f1f4d2e43d15d6addcceb732feff文章来源地址https://www.toymoban.com/news/detail-479491.html
到了这里,关于Zookeeper 基础知识汇总的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!