Hadoop基础--zookeeper原理
Zookeeper 会维护一个具有层次关系的数据结构,它非常类似于一个标准的文件系统,如图 1 所示
zookeeper 这种数据结构有如下这些特点:
- 每个子目录项如 NameService 都被称作为 znode,这个 znode 是被它所在的路径唯一标识,如 Server1 这个 znode 的标识为 /NameService/Server1;
- znode 可以有子节点目录,并且每个 znode 可以存储数据,注意 EPHEMERAL 类型的目录节点不能有子节点目录;
- znode 是有版本的,每个 znode 中存储的数据可以有多个版本,也就是一个访问路径中可以存储多份数据;
- znode 可以是临时节点,一旦创建这个 znode 的客户端与服务器失去联系,这个 znode 也将自动删除,Zookeeper 的客户端和服务器通信采用长连接方式,每个客户端和服务器通过心跳来保持连接,这个连接状态称为 session,如果 znode 是临时节点,这个 session 失效,znode 也就删除了;
- znode 的目录名可以自动编号,如 App1 已经存在,再创建的话,将会自动命名为 App2;
- znode 可以被监控,包括这个目录节点中存储的数据的修改,子节点目录的变化等,一旦变化可以通知设置监控的客户端,这个是 Zookeeper 的核心特性,Zookeeper 的很多功能都是基于这个特性实现的,后面在典型的应用场景中会有实例介绍
统一命名服务(Name Service)
分布式应用中,通常需要有一套完整的命名规则,既能够产生唯一的名称又便于人识别和记住,通常情况下用树形的名称结构是一个理想的选择,树形的名称结构是一个有层次的目录结构,既对人友好又不会重复。说到这里你可能想到了 JNDI,没错 Zookeeper 的 Name Service 与 JNDI 能够完成的功能是差不多的,它们都是将有层次的目录结构关联到一定资源上,但是 Zookeeper 的 Name Service 更加是广泛意义上的关联,也许你并不需要将名称关联到特定资源上,你可能只需要一个不会重复名称,就像数据库中产生一个唯一的数字主键一样。
Name Service 已经是 Zookeeper 内置的功能,你只要调用 Zookeeper 的 API 就能实现。如调用 create 接口就可以很容易创建一个目录节点。
配置管理(Configuration Management)
配置的管理在分布式应用环境中很常见,例如同一个应用系统需要多台 PC Server 运行,但是它们运行的应用系统的某些配置项是相同的,如果要修改这些相同的配置项,那么就必须同时修改每台运行这个应用系统的 PC Server,这样非常麻烦而且容易出错。
像这样的配置信息完全可以交给 Zookeeper 来管理,将配置信息保存在 Zookeeper 的某个目录节点中,然后将所有需要修改的应用机器监控配置信息的状态,一旦配置信息发生变化,每台应用机器就会收到 Zookeeper 的通知,然后从 Zookeeper 获取新的配置信息应用到系统中。
队列管理
Zookeeper 可以处理两种类型的队列:
- 当一个队列的成员都聚齐时,这个队列才可用,否则一直等待所有成员到达,这种是同步队列。
- 队列按照 FIFO 方式进行入队和出队操作,例如实现生产者和消费者模型。
3.3.0 以后 版本新增角色Observer
增加原因:
Zookeeper需保证高可用和强一致性;
当集群节点数目逐渐增大为了支持更多的客户端,需要增加更多Server,然而Server增多,投票阶段延迟增大,影响性能。为了权衡伸缩性和高吞吐率,引入Observer:
Observer不参与投票;
Observers接受客户端的连接,并将写请求转发给leader节点;
加入更多Observer节点,提高伸缩性,同时不影响吞吐率。
Zookeeper Server数目一般为奇数
Leader选举算法采用了Paxos协议;
Paxos核心思想:当多数Server写成功,则任务数据写 成功
如果有3个Server,则两个写成功即可;
如果有4或5个Server,则三个写成功即可。 Server数目一般为奇数(3、5、7)
如果有3个Server,则最多允许1个Server挂掉; 如果有4个Server,则同样最多允许1个Server挂掉 既然如此,为啥要用4个Server?
使用方式,在shell终端输入:echo mntr | nc localhost 2181
命令 | 示例 | 描述 |
conf | echo conf | nc localhost 2181 |
(New in 3.3.0)输出相关服务配置的详细信息。比如端口、zk数据及日志配置路径、最大连接数, session超时时间、serverId等 |
cons | echo cons | nc localhost 2181 |
(New in 3.3.0)列出所有连接到这台服务器的客户端连接/会话的详细信息。包括“接受/发送”的包数量、 session id 、操作延迟、最后的操作执行等信息。 |
crst | echo crst | nc localhost 2181 | (New in 3.3.0)重置当前这台服务器所有连接/会话的统计信息 |
dump | echo dump | nc localhost 2181 | 列出未经处理的会话和临时节点(只在leader上有效)。 |
envi | echo envi | nc localhost 2181 |
输出关于服务器的环境详细信息(不同于conf命令),比如host.name、java.version、java.home、 user.dir=/data/zookeeper-3.4.6/bin之类信息 |
ruok | echo ruok | nc localhost 2181 | 测试服务是否处于正确运行状态。如果正常返回"imok",否则返回空。 |
srst | echo srst | nc localhost 2181 | 重置服务器的统计信息 |
srvr | echo srvr | nc localhost 2181 |
(New in 3.3.0)输出服务器的详细信息。zk版本、接收/发送包数量、连接数、 模式(leader/follower)、节点总数。 |
stat | echo stat | nc localhost 2181 |
输出服务器的详细信息:接收/发送包数量、连接数、模式(leader/follower)、节点总数 、延迟。 所有客户端的列表。 |
wchs | echo wchs | nc localhost 2181 | (New in 3.3.0)列出服务器watches的简洁信息:连接总数、watching节点总数和watches总数 |
wchc | echo wchc | nc localhost 2181 |
(New in 3.3.0)通过session分组,列出watch的所有节点,它的输出是一个与 watch 相关的 会话的节点列表。如果watches数量很大的话,将会产生很大的开销,会影响性能,小心使用。 |
wchp | echo wchp | nc localhost 2181 |
(New in 3.3.0)通过路径分组,列出所有的 watch 的session id信息。它输出一个与 session 相关的路径。如果watches数量很大的话,将会产生很大的开销,会影响性能,小心使用。 |
mntr | echo mntr | nc localhost 2181 |
(New in 3.4.0)列出集群的健康状态。包括“接受/发送”的包数量、操作延迟、 当前服务模式(leader/follower)、节点总数、watch总数、临时节点总数。 |