资料参考来源拉钩Java高薪训练营
文章目录
前言
Zookeeper是一个开源的分布式协调服务,是一个典型的分布式数据一致性解决方案,分布式应用可以基于Zookeeper实现数据订阅/发布、负载均衡、命名服务、集群管理、分布式锁、分布式队列等功能。
一、Zookeeper基本概念
-
集群角色
Zookeeper有Leader、Follower、Observer三种角色,Zookeeper中通过Leader选举来选定一台被称为Leader的机器,Leader提供读写服务,Follower和Observer只提供读服务,但是Observer不参与Leader选举和写操作过半投票策略。 -
会话
会话是客户端和Zookeeper的一个TCP长连接会话,通过心跳检测来保持有效的会话。 -
节点(Znode)
Zookeeper中数据存储在内存中,数据模型是一棵树,有斜杠(/)进行分割的路径,比如/app/test,每个Znode上都会保存自己的数据内容和一系列的属性信息。
节点类型分为持久性节点(Persistent)、临时性节点(Ephemeral)、顺序性节点(Sequential),通过这集中特性组合成这四种节点类型:- 持久节点:被创建后一直存在服务器上,直到删除操作主动清楚
- 持久顺序节点:特性和持久节点一致,额外加上了顺序,在创建时,会在节点名后面加上一个数字后缀,来表示顺序。
- 临时节点:生命周期和客户端会话绑定在一起,客户端会话结束,节点会被自动删除。临时节点不能创建子节点。
- 临时顺序节点:和临时节点特性一直,创建节点时在节点名加上了数字后缀来表示顺序。
-
版本(version)
zookeeper会在节点上存储数据,同时会有一个叫Stat的数据结构,记录了当前数据的版本信息。有点类似于数据库的乐观锁概率,基于版本来操作数据。 -
Watcher(事件监听器)
Watcher是Zookeeper中很重要的特性,Zookeeper允许客户端在指定节点上注册一些Watcher,并在一些特殊事件触发的时候,通知这个客户端,该机制是Zookeeper实现分布式协调服务的重要特性。 -
ACL
ACL是Zookeeper采用的权限控制策略,定义了5种权限:- CREATE:创建节点的权限
- READ:获取节点数据和子节点列表的权限
- WRITE:更新节点的权限
- DELETE:删除子节点的权限
- ADMIN:设置节点ACL的权限
二、Zookeeper使用
1.常用命令
客户端连接Zookeeper:
./zkcli.sh 连接本地的zookeeper服务
./zkCli.sh -server ip:port 连接执行服务器
创建节点:
create [-s][-e] path data acl
其中 -s或-e分别指节点特性,-s是顺序节点,-e是临时节点,若不指定,则创建持久节点。acl用来进行权限控制
读取节点:
ls path
查看指定路径下的子节点列表
get path
获取指定路径节点的数据
更新节点:
set path data [version]
可以指定版本更新节点数据
删除节点:
delete path [version]
2.Zookeeper应用场景
-
数据发布订阅
其实就是配置中心,发布者发布数据到Zookeeper上的节点,通过Watcher通知订阅者来获取数据,实现配置信息的集中式管理和数据的动态更新。
比如一个数据库配置信息jdbc.properties信息可以存储到一个节点上,集群中的机器启动时读取这个配置信息同时注册一个数据变更的Watcher监听,一旦数据发生变更,所有订阅的客户端机器都会收到通知,然后就可以重新去获取最新的配置信息。 -
命名服务
命名服务其实最主要的就是需要给服务生成一个全局唯一的名字,类似数据库主键。通过Zookeeper在创建节点时,可以创建顺序节点,Zookeeper就会自动在节点后面加上一个序号,这个节点的名称就是全局唯一的。 -
集群管理
集群管理中比如集群监控,监控系统对Zookeeper的数据节点注册Watcher监听,当每台服务器在Zookeeper注册一个临时节点时,建通系统就能收到通知新增了机器。当集群中某台机器宕机或者下线,对应的临时节点就会被删除,监控系统也能收到对应的Watcher事件通知。 -
Master选举
最简单的就是所有需要参与Master选举的机器同时向Zookeeper中同一个路径下创建一个名称相同的临时节点,谁创建成功了,谁就是Master。当Master宕机时,临时节点就会被删除,同时通过Watcher通知集群其他机器,重新选举Master。 -
分布式锁
排他锁:和Master选举差不多,都去创建节点,谁能创建成功谁就能获取到锁。没有获取到锁的客户端,注册Watcher监听,当获取到锁的客户端宕机或者执行完业务逻辑主动删除这个临时节点时,Watcher通知其他客户端再来竞争锁。 -
分布式队列
所有客户端在Zookeeper创建临时顺序节点,判断自己是否是序号最小的,如果不是最小的,需要等待,同时向比自己小的最后一个节点注册Watcher监听。等收到Watcher监听后重复上面的步骤。
三、深入进阶
1.ZAB协议
Zookeeper使用的是ZAB协议来作为其数据一致性的核心算法,ZAB是专门为Zookeeper设计的一种支持崩溃恢复的原子广播协议。
ZAB的核心是定义了对于那些会改变Zookeeper服务器数据状态的事务请求的处理方式:
所有事务都必须由一个全局唯一的服务器来协调处理,这样的服务器叫Leader服务器,余下的服务器器称为Follower服务器,Leader服务器负责将客户端事务请求转化成一个事务Proposal(提议),然后发送给所有的Follower服务器,等待超过半数的Follower服务器进行了正确的反馈过后,Leader再次向所有的Follower服务器发起commit消息,进行事务的提交。
ZAB协议包括两种基本模式:
- 崩溃恢复模式:
当服务器启动过程中,或者Leader服务器出现网络异常、崩溃推出或重启等情况,ZAB协议就会进入到崩溃恢复模式,同时选举出新的Leader服务器。当选举出新的Leader服务器,同时集群中已经有过半的机器与Leader服务器完成了状态同步之后,ZAB协议就会退出恢复模式。 - 消息广播模式:
当集群中已经有过半的服务器与Leader完成状态同步后,那么就进入到消息广播模式。Zookeeper只允许一个Leader服务器来进行事务处理,就算客户端请求到一个Follower服务器,这个Follower会判断是否是事务请求,也就是写请求,如果是事务请求,那么会把这个请求转发到Leader服务器来处理。Leader服务器接收到请求后,会生成对应的事务提议并发起一轮广播协议。
ZAB协议需要确保那些已经在Leader服务器上提交的事务最终被所有服务器提交
ZAB协议需要确保丢弃那么只在Leader服务器上被提出但没提交的事务
2.服务器角色
1.Leader
Leader服务器是Zookeeper集群工作的核心,主要负责:
- 事务请求的唯一调度者,保证集群事务处理的顺序性。
- 集群内部各个服务器的调度者。
请求处理链:
- PrepRequestProcessor。请求预处理器,识别当前请求是否是事务请求,对于事务请求,PrepRequestProcessor会对其进行一系列的预处理,比如创建请求事务头、事务体、会话检查、ACL检查、版本检查等。
- ProposalRequestProcessor。事务投票处理器,Leader服务器事务处理流程的发起者,对于非事务请求,ProposalRequestProcessor会将请求转发到CommitProcessor处理器,不再做其他处理。而对于事务请求,处理转发到CommitProcessor外,还会根据请请求类型创建对应的Proposal提议,并发送给所有Follower服务器来发起一起集群内事务投票。同时还会将事务请求转发到SyncRequestProcessor进行事务日志的记录。
- SyncRequestProcessor。事务日志记录处理器。
- AckRequestProcessor。负责在SyncRequestProcessor完成事务日志记录后,向Proposal的投票收集器发送ACK反馈。
- CommitProcessor。事务提交处理器,对于非事务请求,直接转发给下一个处理器,对于事务请求,需要等待Proposal投票,知道Proposal可以被提交。
- ToBeCommitProcessor。该处理器有一个toBeApplied队列,存储已经被CommitProcessor处理过的可被提交的Proposal。会将请求交付给FinalRequestProcessor处理,处理完成后移出队列。
- FinalRequestProcessor。用来进行客户端请求返回之前的操作,包括创建客户端请求响应,针对事务,该处理器还会负责将事务应用到内存数据库中。
2.Follower
Follower作为Zookeeper集群状态中的跟随者,主要负责:
- 处理客户端非事务请求(读请求),转发事务请求给Leader服务器
- 参与事务请求Proposal的投票
- 参与Leader选举
请求处理链:
- FollowerRequestProcessor。其作用是识别当前请求是否是事务请求,如果是,那么会转发给Leader服务器。
- SendAckRequestProcessor。事务日志反馈功能,在完成事务日志记录后,向
3.Observer
Observer是Zookeeper从3.0版本开始引入的服务器角色,工作原理和Follower基本一致,只是不参与事务请求Proposal的投票和Leader选举,主要是用于在不影响集群事务处理能力的前提下提升集群的非事务处理能力。
3.服务器启动流程
单机版服务器启动流程:
集群版服务器启动流程: