定义: 开源的,分布式的 为分布式应用提供协调服务的apache项目
从设计模式角度,zookeeper 是基于观察者模式设计的分布式服务管理框架。 负责管理和存储大家都关心的数据。接受观察者的注册。 如果数据发生变化,zookeeper 会通知已经注册的观察者作出相应的响应
Zookeeper= 文件系统 + 监听机制
Zookeeper 的特点:
- 一个leader ,多个follower 组成集群
- 集群中只要有半数存活,zk集群就能正常工作
- 全局数据一致:每个Server 保存一份相同的数据副本。客户端无论连接哪个server,获取到的数据都一样
- 来自同一个客户端的更新请求按其发送顺序,依次执行。
- 数据更新原子性,要么成功,要么失败
- 实时性,在一定时间范围内,客户端能读到最新数据。也就是服务之间同步数据的时间很短。(因为数据量小)
zookeeper的数据结构
zookeeper 数据结构为树形结构,每个节点称作一个ZNode。 每个ZNode默认存储1M 的数据,每个ZNode 通过其路劲来标识。
zookeeper 单机模式安装
- 安装JDK ,加压zookeeper 安装包
- 将conf文件夹下的 zoo_sample.cfg 修改为zoo.cfg
- 打开zoo.cfg 修改dataDir 路径
启动服务端: bin/zkServer.sh start
关闭服务端: bin/zkServer.sh stop
启动客户端: bin/zkCli.sh
退出: quit
zoo.cfg 中常用配置参数说明
- tickTime=2000 心跳时间,单位是毫秒。服务之间或者客户端与服务器之间维持心跳的时间间隔
- initLimit=10 leader 与 Follower 之间初始连接时能容忍的最多心跳数。
也就是10 个 tickTime(20 秒)
此配置表示,允许 follower (相对于 leader 而言的“客户端”)连接 并同步到 leader 的初始化连接时间,它以 tickTime 的倍数来表示。当超过设置倍数的 tickTime 时间,则连接失败。
如果在设定的时间段内,半数以上的跟随者未能完成同步,领导者便会宣布放弃领导地位,进行另一次的领导选举。如果zk集群环境数量确实很大,同步数据的时间会变长,因此这种情况下可以适当调大该参数。默认为10。
- syncLimit=5 Leader 与 Follower 之间最大的相应时间单位。 (10 秒)如果超过,Leader 会认为Follower死掉,会从服务器中移除
- dataDir: 用于保存zookeeper 数据的目录
- clientPort=2181 客户端连接端口
zookeeper 内部原理
选举机制
- 半数机制: 集群中半数以上机器存活,集群可用。 所以zk适合安装奇数台。(也就是说 如果有2个zookeeper,只要一个挂掉就不能用。因为1 没有 过半。所以2个zk的死亡容忍度为0; 同理,要是有三个,挂掉1个,还有2个,过半了,所以3台zk的死亡容忍度为1 依次类推 4 -1 , 5-> 2 6->2 发现2n和2n-1 的死亡容忍度是一样的。为了高效就必须多增加一台。)
- zookeeper 配置文件中没有指定Master 和Slave ,但是zk工作时有一个节点是Leader,其他为Follower。 Leader 是通过内部的选举机制产生的
Leader 的选举
1. 所有节点一启动就先给自己投一票,然后给所有节点广播投票信息。
2. 节点收到广播的投票信息后,发现投给某个节点比投给自己好,就会更改自己的投票信息,并且广播更改
3. 票数过半的节点作为Leader
ZK 分布式集群部署
- 创建zkData目录,在该目录下创建myid文件,在文件中写入与server对于的编号
- 修改conf/zoo_sample.cfg 文件为zoo.cfg, 修改dataDir 路劲为zkData 的路劲
- 在zoo.cfg 添加以下配置
#######################cluster##########################
server.2=hadoop102:2888:3888
erver.3=hadoop103:2888:3888
server.4=hadoop104:2888:3888
server.A=B:C:D
A 表示 第几号服务器,和myid中写的对应
B 表示该zookeeper 所在服务器地址
C Follower 与 Leader 通信的端口
D 专门用于选举的端口
- 启动集群: bin/zkServer.sh start
- 查看集群状态: bin/zkServer.sh status