它负责存储和管理大家都关心的数据,然后接受观察者的注册,一旦这些数据的状态发生变化,Zookeeper 就将负责通知这些已经在 Zookeeper 上注册的那些观察者做出相应的反应。
ZooKeeper 数据模型的结构与 Unix 文件系统很类似,整体上可以看作一棵树,每个节点称为一个 ZNode。每个 ZNode 默认能够存储 1MB 的数据,每个 ZNode 都可以通过其路径唯一标识。
在分布式系统下,经常需要对应用/服务进行统一命名,便于识别。例如:IP 不容易记住,而域名容易记住。
客户端能够实时洞察到服务器上下线的变化。
在 ZooKeeper 中记录每台服务器的访问数,让访问数最少的服务器去处理最新的客户端请求。
Zookeeper 中的配置文件 zoo.cfg 中参数含义解读如下:
tickTime = 2000:通信心跳时间,Zookeeper 服务器与客户端心跳时间,单位毫秒。
initLimit = 10:LF 初始通信时限。Leader 和 Follower 初始连接时能容忍的最多心跳数(tickTime的数量)
syncLimit = 5:LF 同步通信时限。Leader 和 Follower 之间通信时间如果超过 syncLimit * tickTime,Leader 认为 Follower 死掉,从服务器列表中删除 Follower。
dataDir:保存 Zookeeper 中的数据。注意:默认的 tmp 目录,容易被 Linux 系统定期删除,所以一般不用默认的 tmp 目录。
clientPort = 2181:客户端连接端口,通常不做修改。
服务器1启动,发起一次选举。服务器1投自己一票。此时服务器1票数一票,不够半数以上(3票),选举无法完成,服务器1状态保持为LOOKING。
服务器2启动,再发起一次选举。服务器1和2分别投自己一票并交换选票信息:此时服务器1发现服务器2的 myid 比自己目前投票推举的(服务器1)大,更改选票为推举服务器2。此时服务器1票数0票,服务器2票数2票,没有半数以上结果,选举无法完成,服务器1,2状态保持LOOKING。
服务器3启动,发动一次选举。此时服务器1和2都会更改选票为服务器3.此次投票结果:服务器1为0票,服务器2为0票,服务器3为3票。此时服务器3的票数已经超过半数,服务器3当选 Leader。服务器1,2更改状态为FOLLOWING,服务器3更改状态为 LEADING。
服务器4启动,发起一次选举。此时服务器1,2,3已经不是LOOKING状态,不会更改选票信息。交换选票信息结果:服务器3为3票,服务器4为1票。此时服务器4服从多数,更改选票信息为服务器3,并更改状态为FOLLOWING。
服务器5启动,同4一样当小弟。
SID:服务器ID。用来唯一标识一台 ZooKeeper 集群中的机器,每台机器不能重复,和 myid 一致。
ZXID:事务ID。ZXID 是一个事务 ID,用来标识一次服务器状态的变更。在某一时刻,集群中的每台机器的ZXID值不一定完全一致,这和 ZooKeeper 服务器对于客户端“更改请求”的处理逻辑有关。
Epoch:每个 Leader 任期的代号。每次 Leader 时同一轮投票过程中的逻辑时钟值是相同的。每投完一次票这个数据就会增加。
先比Epoch,再比ZXID,看谁的数据更完整。
当 ZooKeeper 集群中的一台服务器出现以下两种情况之一时, 就会进行Leader 选举:
而当一台机器进入 Leader 选举流程时,当前集群也可能会处于一下两种状态:
命令基本语法 | 功能描述 |
---|---|
help | 使用 ls 命令来查看当前 znode 的子节点 [可监听] -w:监听子节点变化 -s:附加次级信息 |
create | 普通创建 -s:含有序列 -e:临时(重启或者超时消失) |
get path | 获取节点的值 [可监听] -w:监听节点的内容变化 -s:附加次级信息 |
set | 设置节点的具体值 |
stat | 查看节点状态 |
delete | 删除节点 |
deleteall | 递归删除节点 |
[zookeeper]
cZxid = 0x0:创建节点的事务。每次修改 ZooKeeper 状态都会产生一个 ZooKeeper 事务 ID。事务 ID 是 ZooKeeper 中所有修改的总的次序。每次修改都有唯一的 zxid,如果 zxid1 小于 zxid2,那么 zxid1 再 zxid2之前发生。
ctime = Thu Jan 01 08:00:00 CST 1970:znode 被创建的毫秒数(从1970年开始)
mZxid = 0x0:znode 最后更新的事务 zxid
mtime = Thu Jan 01 08:00:00 CST 1970:znode 最后修改的毫秒数(从1970年开始)
pZxid = 0x0:znode 最后更新的子节点 zxid
cversion = -1:znode 子节点变化号,znode 子节点修改次数
dataVersion = 0:znode 数据变化号
aclVersion = 0:znode 访问控制列表的变化号
ephemeralOwner = 0x0:如果是临时节点,这个是 znode 拥有者的 session id。如果不是临时节点则是0。
dataLength = 0:znode 的数据长度。
numChildren = 1:znode 子节点数量。
持久化目录节点:客户端与 Zookeeper 断开连接后,该节点依旧存在。
持久化顺序编号目录节点:客户端与 Zookeeper 断开连接后,该节点依旧存在,只是 Zookeeper 给该节点名称进行顺序编号。
临时目录节点:客户端与 Zookeeper 断开连接后,该节点被删除。
临时顺序编号目录节点:客户端与 Zookeeper 断开连接后,该节点被删除,只是 Zookeeper 给该节点名称进行顺序编号。
说明:创建 znode 时设置顺序标识,znode 名称后会附加一个值,顺序号是一个单调递增的计数器,由父节点维护。
注意:在分布式系统中,顺序号可以被用于为所有的事件进行全局排序,这样客户端可以通过顺序号推断事件的顺序。
客户端注册监听它关心的目录节点,当目录节点发生变化(数据改变、节点删除、子目录节点增加删除)时,ZooKeeper 会通知客户端。监听机制保证 ZooKeeper 保存的任何的数据的任何改变都能快速的响应到监听了该节点的应用程序。
1)首先要有一个main()线程
2)在main线程中创建Zookeeper客户端,这时就会创建两个线程,一个负责网络连接通信(connect),一个负责监听(listener)。
3)通过connect线程将注册的监听事件发送给Zookeeper。
4)在Zookeeper的注册监听器列表中将注册的监听事件添加到列表中。
5)Zookeeper监听到有数据或路径变化,就会将这个消息发送给listener线程。
6)listener线程内部调用了process()方法。
WATCHER::
WatchedEvent state:SyncConnected type:NodeDataChanged path:/sanguo
注意:在hadoop103再多次修改/sanguo的值,hadoop104上不会再收到监听。因为注册一次,只能监听一次。想再次监听,需要再次注册。
WATCHER::
WatchedEvent state:SyncConnected type:NodeChildrenChanged path:/sanguo
注意:节点的路径变化,也是注册一次,生效一次 。想多次生效,就需要多次注册。