分布式应用程序协调服务 ZooKeeper
Posted zyybky
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了分布式应用程序协调服务 ZooKeeper相关的知识,希望对你有一定的参考价值。
1、简介:
ZooKeeper 是一个分布的、开源的协调服务,它主要是用来解决分布式应用中经常遇到的一些数据管理问题。统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等,简化分布式应用协调及其管理的难度,提供高性能的分布式服务。
2、ZooKeeper 目标:
封装好复杂易出错的关键服务,将简单易用的接口和性能高效、功能稳定的系统提供给用户。
3、ZooKeeper 工作方式:
本身可以以 Standalone 模式安装运行,不过它的长处在于通过分布式 ZooKeeper 集群(一个Leader,多个 Follower),基于一定的策略来保证 ZooKeeper 集群的稳定性和可用性,从而实现分布式应用的可靠性。
最新的版本可以在官网 http://zookeeper.apache.org/releases.html 来下载 zookeeper 的最新版本。
4、ZooKeeper 特点:
最终一致性:为客户端展示同一个视图,这是 ZooKeeper 里面一个非常重要的功能。
可靠性:如果消息被一台服务器接受,那么它将被所有的服务器接受。
实时性:ZooKeeper 不能保证两个客户端能同时得到刚更新的数据,如果需要最新数据,应该在读数据之前调用 sync() 接口。
独立性:各个 Client 之间互不干预。
原子性:更新只能成功或者失败,没有中间状态。
顺序性:所有 Server,同一消息发布顺序一致。
5、ZooKeeper 工作原理:
每个 Server 在内存中存储了一份数据;
ZooKeeper 启动时,将从实例中选举一个 Leader(Paxos 协议);
Leader 负责处理数据更新等操作(Zab 协议);
一个更新操作成功,当且仅当大多数 Server 在内存中成功修改数据。
选举机制:
全新集群选举:每个机器都给自己投票、投票数过半选举结束。myid 大的权重大。
非全新集群选举:数据ID、服务器ID和逻辑时钟
逻辑时钟小的选举结果被忽略,重新投票;
统一逻辑时钟后,数据 ID 大的胜出;
数据 ID 相同,服务器 ID 大的胜出。
Paxos 协议:
它是一个基于消息传递的一致性算法。Paxos 有一个前提:没有拜占庭将军问题。就是说 Paxos 只有在一个可信的计算环境中才能成立,这个环境是不会被入侵所破坏的。
工作流程:提出提议,议员超过半数则提议生效,通知所有。顺序性提议编号。
ZAB 协议:
用来保障分布式数据一致性。ZAB 是一种支持崩溃恢复的消息广播协议,采用类似 2PC 的广播模式保证正常运行时性能,并使用基于 Paxos 的策略保证崩溃恢复时的一致性。
ZAB 协议中节点存在四种状态:
Leading:当前节点为集群 Leader,负责协调事务
Following:当前节点为 Follower 在 Leader 协调下执行事务
Looking:集群没有正在运行的 Leader, 正处于选举过程
Observing:节点跟随 Leader 保存系统最新的状态提供读服务,但不参与选举和事务投票
ZAB 协议的两种工作模式:
广播模式:当集群正常运行过程中,Leader 使用广播模式保证各 Follower 节点的一致性
恢复模式:集群启动或 Leader 崩溃时系统进入恢复模式,选举 Leader 并将集群中各节点的数据同步到最新状态
ZooKeeper 集群中每个节点都会存储系统数据的完整副本,可以独立处理读请求。
当 Follower 收到写请求时会将其转发给 Leader, Leader 为每个写请求分配唯一的全局有序的事务ID(Zookeeper Transaction Id, ZXID)。
Leader 在广播模式下协调各 Follower 完成事务,并保证集群更新到一致的状态。
6、ZooKeeper 角色:
领导者(Leader):领导者负责进行投票的发起和决议,更新系统状态,处理写请求。
跟随者(Follwer):Follower 用于接收客户端的读写请求并向客户端返回结果,在选主过程中参与投票。
观察者(Observer):观察者可以接收客户端的读写请求,并将写请求转发给 Leader,但 Observer节点不参与投票过程,只同步 leader 状态,Observer 的目的是为了扩展系统,提高读取速度。
客户端(Client):执行读写请求的发起方。
7、ZooKeeper 的数据模型:
树形结构的命名空间,与文件系统类似,层次化的目录结构,命名符合常规文件系统规范;
数据大小不超过 1MB(可配置),数据读写要保证完整性;
每个节点在 zookeeper 中叫做 znode,并且其有一个唯一的路径标识;
节点(znode)都可以存数据,可以有子节点,节点不支持重命名;
节点 Znode 可以包含数据和子节点(临时节点不能有子节点);
Znode 中的数据可以有多个版本,比如某一个路径下存有多个数据版本,那么查询这个路径下的数据需带上版本;
客户端应用可以在节点上设置监视器(Watcher);
节点不支持部分读写,而是一次性完整读写;
Znode 有两种类型,短暂的(ephemeral)和持久的(persistent);
Znode 的类型在创建时确定并且之后不能再修改;
短暂 znode 的客户端会话结束时,zookeeper 会将该短暂 znode 删除,短暂 znode 不可以有子节点;
持久 znode 不依赖于客户端会话,只有当客户端明确要删除该持久 znode 时才会被删除;
Znode 有 四 种 形 式 的 目 录 节 点 ,PERSISTENT、PERSISTENT_SEQUENTIAL、EPHEMERAL、EPHEMERAL_SEQUENTIAL。
节点属性:
dataVersion(数据版本号)
cversion(子节点版本号)
ACLVersion
cZxid(创建的事务id)
mZxid(修改的事务id)
ctime(节点创建时间)
mtime(节点更新时间)
ephemeralOwner(0x0:永久节点)
8、数据发布与订阅:
创建数据目录,订阅者初次启动的时候去 ZK 指定的节点获取相关的订阅信息;获取数据的同时,设置监听(监听节点数据的变化);一旦节点数据改变,触发监听,订阅者收到事件通知,获取数据,再次设置监听。
注:统一管理的数据不能太大
9、ZooKeeper 主要应用场景:
(1)统一命名服务:
分布式环境下,经常需要对应用/服务进行统一命名,便于识别不同服务;
类似于域名与 ip 之间对应关系,域名容易记住;
通过名称来获取资源或服务的地址,提供者等信息;
按照层次结构组织服务/应用名称;
可将服务名称以及地址信息写到 ZooKeeper 上,客户端通过 ZooKeeper 获取可用服务列表类。
(2)配置管理服务:
分布式环境下,配置文件管理和同步是一个常见问题;
一个集群中,所有节点的配置信息是一致的;
对配置文件修改后,希望能够快速同步到各个节点上;
配置管理可交由 ZooKeeper 实现,可将配置信息写入 ZooKeeper 的一个 znode 上,各个节点监听这个 znode ,一旦 znode 中的数据被修改,ZooKeeper 将通知各个节点。
(3)集群管理:
分布式环境中,实时掌握每个节点的状态是必要的;
可根据节点实时状态作出一些调整;
可交由 ZooKeeper 实现,可将节点信息写入 ZooKeeper 的一个 znode 上,监听这个 znode 可获取它的实时状态变化。
实现思路:
在 ZooKeeper 上创建一个临时节点,然后每个 Server 在它们创建目录节点的父目录节点上调用 getChildren(String path, boolean watch) 方法并设置 watch 为 true,由于是临时节点,当创建它的 Server 死去,这个目录节点也随之被删除,所以 Children 将会变化,这时 getChildren 上的 Watch 将会被调用,所以其它 Server 就知道已经有某台 Server 死去了。新增 Server 也是同样的原理。
(4)分布式通知和协调:
分布式环境中,经常存在一个服务需要知道它所管理的子服务的状态;
NameNode 须知道各 DataNode 的状态
JobTracker 须知道各 TaskTracker 的状态
心跳检测机制可通过 ZooKeeper 实现,信息推送可由 ZooKeeper 实现(发布/订阅模式)
(5)分布式锁:保持独占、控制时序(序列化)
Client 首先在 ZK 上指定的目录创建节点(节点是一个非序列化的临时节点),只能有一个创建成功,谁创建成功,谁就获得访问数据文件的权限,操作完成断开和 ZK 的连接,其他应用如果需要操作这个文件,就去监听这个目录是否存在。
(6)分布式队列:
两种队列:
当一个队列的成员都聚齐时,这个队列才可用,否则一直等待所有成员到达,这种是同步队列。
队列按照 FIFO 先进先出方式进行入队和出队操作,例如实现生产者和消费者模型。(可通过分布式锁实现)
同步队列:
一个 job 由多个 task 组成,只有所有任务完成后,job 才运行完成。
可为 job 创建一个/job 目录,然后在该目录下,为每个完成的 task 创建一个临时 znode,一旦临时节点数目达到 task 总数,则 job 运行完成。
同步队列实现思路:
创建一个父目录 /synchronizing,每个成员都监控标志(Set Watch)位目录 /synchronizing/start 是否存在,然后每个成员都加入这个队列,加入队列的方式就是创建 /synchronizing/member_i 的临时目录节点,然后每个成员获取 / synchronizing 目录的所有目录节点,也就是 member_i。判断 i 的值是否已经是成员的个数,如果小于成员个数等待 /synchronizing/start 的出现,如果已经相等就创建/synchronizing/start。
FIFO 队列实现思路:
实现的思路也非常简单,就是在特定的目录下创建 SEQUENTIAL 类型的子目录 /queue_i,这样就能保证所有成员加入队列时都是有编号的,出队列时通过 getChildren( ) 方法可以返回当前所有的队列中的元素,然后消费其中最小的一个,这样就能保证 FIFO。
10、ZooKeeper 集群配置:
(1)卸载 openjdk,安装 jdk 环境,配置环境变量
(2)时间同步、防火墙处理
(3)配置主机名到 ip 地址的映射
[root@znode1 ~]# cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 192.168.100.31 znode1 192.168.100.32 znode2 192.168.100.33 znode3
(4)三个节点分别:下载、解压 zookeeper-3.4.14.tar.gz 至安装目录(例:/usr/local/src/zookeeper-3.4.14)
(5)创建同名软链接
(6)修改 ZooKeeper 配置文件
[root@znode1 ~]# cd /usr/local/src/zookeeper/conf/ [root@znode1 conf]# cp zoo_sample.cfg zoo.cfg [root@znode1 conf]# vim zoo.cfg dataDir=/data/zookeeper clientPort=2181 server.1=znode1:2888:3888 #心跳端口、选举端口 server.2=znode2:2888:3888 server.3=znode3:2888:3888 # 参数说明 tickTime=2000 #心跳间隔 initLimit=10 #Follower 服务器初始化连接时最长能忍受多少个心跳时间间隔数 syncLimit=5 # Leader 与 Follower 之间发送消息,请求和应答时间长度,最长不能超过多少个 tickTime 的时间长度 dataDir #Zookeeper保存数据的目录,默认情况下Zookeeper将写数据的日志文件也保存在这个目录里。 clientPort #这个端口就是客户端(应用程序)连接 Zookeeper 服务器的端口,Zookeeper 会监听这个端口接受客户端的访问请求。 server.A=B:C:D #A 为数字,表示第几号服务器;B 是这个服务器的 IP 地址或主机名映射;C 第一个端口用来集群成员的信息交换,表示这个服务器与集群中的 Leader 服务器交换信息的端口;D 是在 leader 挂掉时专门用来进行选举 leader 所用的端口。
(7)在数据目录下创建 myid 文件
[root@znode1 ~]# cat /data/zookeeper/myid 1
(8)启动 ZooKeeper 集群
[root@znode1 ~]# /usr/local/src/zookeeper/bin/zkServer.sh start ZooKeeper JMX enabled by default Using config: /usr/local/src/zookeeper/bin/../conf/zoo.cfg Starting zookeeper ... STARTED [root@znode1 ~]# jps # 查看进程 1397 Jps 1372 QuorumPeerMain [root@znode1 ~]# /usr/local/src/zookeeper/bin/zkServer.sh status ZooKeeper JMX enabled by default Using config: /usr/local/src/zookeeper/bin/../conf/zoo.cfg Mode: follower
[root@znode2 ~]# /usr/local/src/zookeeper/bin/zkServer.sh start ZooKeeper JMX enabled by default Using config: /usr/local/src/zookeeper/bin/../conf/zoo.cfg Starting zookeeper ... STARTED [root@znode2 ~]# jps 1291 Jps 1260 QuorumPeerMain [root@znode2 ~]# /usr/local/src/zookeeper/bin/zkServer.sh status ZooKeeper JMX enabled by default Using config: /usr/local/src/zookeeper/bin/../conf/zoo.cfg Mode: leader
[root@znode3 ~]# /usr/local/src/zookeeper/bin/zkServer.sh start ZooKeeper JMX enabled by default Using config: /usr/local/src/zookeeper/bin/../conf/zoo.cfg Starting zookeeper ... STARTED [root@znode3 ~]# jps 1330 QuorumPeerMain 1355 Jps [root@znode3 ~]# /usr/local/src/zookeeper/bin/zkServer.sh status ZooKeeper JMX enabled by default Using config: /usr/local/src/zookeeper/bin/../conf/zoo.cfg Mode: follower
(9)链接
[root@znode1 ~]# /usr/local/src/zookeeper/bin/zkCli.sh # 本地链接 ...... [zk: localhost:2181(CONNECTED) 0] [root@znode2 ~]# /usr/local/src/zookeeper/bin/zkCli.sh -server znode3 # 远程链接 ...... [zk: znode3(CONNECTED) 0]
(9)简单命令
创建:create [-se] [path]
-s:序列化;-e:临时节点
ls、get、ls2
[zk: localhost:2181(CONNECTED) 0] ls / [zookeeper] [zk: localhost:2181(CONNECTED) 1] create /data 123 Created /data [zk: localhost:2181(CONNECTED) 2] ls / [zookeeper, data] [zk: localhost:2181(CONNECTED) 3] get /data 123 cZxid = 0x400000005 ctime = Fri May 22 18:23:24 CST 2020 mZxid = 0x400000005 mtime = Fri May 22 18:23:24 CST 2020 pZxid = 0x400000005 cversion = 0 dataVersion = 0 aclVersion = 0 ephemeralOwner = 0x0 dataLength = 3 numChildren = 0 [zk: localhost:2181(CONNECTED) 4] ls2 /data [] cZxid = 0x400000005 ctime = Fri May 22 18:23:24 CST 2020 mZxid = 0x400000005 mtime = Fri May 22 18:23:24 CST 2020 pZxid = 0x400000005 cversion = 0 dataVersion = 0 aclVersion = 0 ephemeralOwner = 0x0 dataLength = 3 numChildren = 0
删除:delete [-se] [path]
rmr [path]
quota
setquota -n|-b [val] [path]
n : 表示子节点的最大个数
b : 表示数据值的最大长度
val : 子节点最大个数或数据值的最大长度
listquota
delquota
history
redo
以上是关于分布式应用程序协调服务 ZooKeeper的主要内容,如果未能解决你的问题,请参考以下文章