1.Zookeeper 的安装&概述
1.1. Zookeeper 简介
Zookeeper是一个开源的分布式的,为分布式应用提供协调服务的Apache项目。
zk提供的服务
Naming service //按名称区分集群中的节点.
Configuration management //对加入节点的最新化处理。
- Cluster management //实时感知集群中节点的增减.
- Leader election //leader选举
- Locking and synchronization service //修改时锁定数据,实现容灾.
- Highly reliable data registry //节点宕机数据也是可用的。
1.2. ZK 的工作机制
1.4. ZK 架构
1.4.1 名词解释
1.Client
从server获取信息,周期性发送数据给server,表示自己还活着。
client连接时,server回传ack信息。
如果client没有收到reponse,自动重定向到另一个server.
2.Server
zk集群中的一员,向client提供所有service,回传ack信息给client,表示自己还活着。
3.ensemble
一组服务器。
最小节点数是3.
4.Leader
如果连接的节点失败,自定恢复,zk服务启动时,完成leader选举。
5.Follower
追寻leader指令的节点。
1.4.2 整体解释
- 1)Zookeeper:一个领导者(leader),多个跟随者(follower)组成的集群。
- 2)Leader负责进行投票的发起和决议,更新系统状态
- 3)Follower用于接收客户请求并向客户端返回结果,在选举Leader过程中参与投票
- 4)集群中只要有半数以上节点存活,Zookeeper集群就能正常服务。
- 5)全局数据一致:每个server保存一份相同的数据副本,client无论连接到哪个server,数据都是一致的。
- 6)更新请求顺序进行,来自同一个client的更新请求按其发送顺序依次执行。
- 7)数据更新原子性,一次数据更新要么成功,要么失败。
- 8)实时性,在一定时间范围内,client能读到最新数据。
1.5. znode
ZooKeeper数据模型的结构与Unix文件系统很类似,整体上可以看作是一棵树,每个节点称做一个ZNode。每一个ZNode默认能够存储1MB的数据,每个ZNode都可以通过其路径唯一标识
zk中的节点,维护了stat,由Version number, Action control list (ACL), Timestamp,Data length.构成.
data version //数据写入的过程变化
ACL //action control list,
1.6. 节点类型
1.持久节点
client结束,还存在。
2.临时节点
在client活动时有效,断开自动删除。临时节点不能有子节点。
leader推选时使用。
3.序列节点
在节点名之后附加10个数字,主要用于同步和锁.
1.7. Session
Session中的请求以FIFO执行,一旦client连接到server,session就建立了。sessionid分配client.
client以固定间隔向server发送心跳,表示session是valid的,zk集群如果在超时时候,没有收到心跳,
判定为client挂了,与此同时,临时节点被删除。
1.8. Watches
观察。
client能够通过watch机制在数据发生变化时收到通知。
client可以在read 节点时设置观察者。watch机制会发送通知给注册的客户端。
观察模式只触发一次。
session过期,watch机制删除了。
1.9. zk工作流程
zk集群启动后,client连接到其中的一个节点,这个节点可以是leader,也可以是follower。
连通后,node分配一个id给client,发送ack信息给client。
如果客户端没有收到ack,连接到另一个节点。
client周期性发送心跳信息给节点保证连接不会丢失。
如果client读取数据,发送请求给node,node读取自己数据库,返回节点数据给client.
如果client想要在 zk 中存储数据,将路径和数据发送给server,server转发给leader。
leader再补发请求给所有follower。只有大多数(超过半数)节点成功响应,则
写操作成功。
1.10 zk 应用场景
1.10.1 统一命名服务
1.10.2 统一配管理
1.10.3 统一集群管理
1.10.4 服务器动态上下线
1.10.5 软负载均衡
2.Zookeeper 完全分布式的安装&基本使用
2.1 安装
2.1.1 高可用安装
2.2.2 完全分布式安装
1 | 1.挑选3台主机 |
2.2.3 zoo.cfg 文件中配置参数的含义
1 | 1)tickTime=2000:通信心跳数 |
2.2 ZK客户端的连接
1 | $>zkCli.sh -server cs1:2181 //进入zk命令行 |
2.3 监听测试
注意点: 注册的监听只能使用一次, 监听完毕后需要重新注册.
1 | =======节点值的变化的监听========== |
3. ZK 内部机制
3.1 选举机制
3.1.1. zookeeper的选举机制(全新集群paxos)
以一个简单的例子来说明整个选举的过程.
假设有五台服务器组成的zookeeper集群,它们的id从1-5,同时它们都是最新启动的,也就是没有历史数据,在存放数据量这一点上,都是一样的.假设这些服务器依序启动,来看看会发生什么.
1) 服务器1启动,此时只有它一台服务器启动了,它发出去的报没有任何响应,所以它的选举状态一直是LOOKING状态
2) 服务器2启动,它与最开始启动的服务器1进行通信,互相交换自己的选举结果,由于两者都没有历史数据,所以id值较大的服务器2胜出,但是由于没有达到超过半数以上的服务器都同意选举它(这个例子中的半数以上是3),所以服务器1,2还是继续保持LOOKING状态.
3) 服务器3启动,根据前面的理论分析,服务器3成为服务器1,2,3中的老大,而与上面不同的是,此时有三台服务器选举了它,所以它成为了这次选举的leader.
4) 服务器4启动,根据前面的分析,理论上服务器4应该是服务器1,2,3,4中最大的,但是由于前面已经有半数以上的服务器选举了服务器3,所以它只能接收当小弟的命了.
5) 服务器5启动,同4一样,当小弟.
3.1.2. 非全新集群的选举机制(数据恢复)
那么,初始化的时候,是按照上述的说明进行选举的,但是当zookeeper运行了一段时间之后,有机器down掉,重新选举时,选举过程就相对复杂了。
需要加入数据id、leader id和逻辑时钟。
数据id:数据新的id就大,数据每次更新都会更新id。
Leader id:就是我们配置的myid中的值,每个机器一个。
逻辑时钟:这个值从0开始递增,每次选举对应一个值,也就是说: 如果在同一次选举中,那么这个值应该是一致的 ; 逻辑时钟值越大,说明这一次选举leader的进程更新.
选举的标准就变成:
1、逻辑时钟小的选举结果被忽略,重新投票
2、统一逻辑时钟后,数据id大的胜出
3、数据id相同的情况下,leader id大的胜出
根据这个规则选出leader。
3.2 stat 的结构
- 1)czxid- 引起这个znode创建的zxid,创建节点的事务的zxid
- 每次修改ZooKeeper状态都会收到一个zxid形式的时间戳,也就是ZooKeeper事务ID。
事务ID是ZooKeeper中所有修改总的次序。每个修改都有唯一的zxid,如果zxid1小于zxid2,那么zxid1在zxid2之前发生。
- 每次修改ZooKeeper状态都会收到一个zxid形式的时间戳,也就是ZooKeeper事务ID。
- 2)ctime - znode被创建的毫秒数(从1970年开始)
- 3)mzxid - znode最后更新的zxid
- 4)mtime - znode最后修改的毫秒数(从1970年开始)
- 5)pZxid-znode最后更新的子节点zxid
- 6)cversion - znode子节点变化号,znode子节点修改次数
- 7)dataversion - znode数据变化号
- 8)aclVersion - znode访问控制列表的变化号
- 9)ephemeralOwner- 如果是临时节点,这个是znode拥有者的session id。如果不是临时节点则是0。
- 10)dataLength- znode的数据长度
- 11)numChildren - znode子节点数量
4. 通过 JavaAPI 访问 ZK
4.1 添加Maven 依赖
1 | 9.1[pom.xml] |
4.2 Java 代码
1 | * 对应关系: |