Hadoop基础--zookeeper原理

Zookeeper 会维护一个具有层次关系的数据结构，它非常类似于一个标准的文件系统，如图 1 所示

图 1 Zookeeper 数据结构

zookeeper 这种数据结构有如下这些特点：

1. 每个子目录项如 NameService 都被称作为 znode，这个 znode 是被它所在的路径唯一标识，如 Server1 这个 znode 的标识为 /NameService/Server1；
2. znode 可以有子节点目录，并且每个 znode 可以存储数据，注意 EPHEMERAL 类型的目录节点不能有子节点目录；
3. znode 是有版本的，每个 znode 中存储的数据可以有多个版本，也就是一个访问路径中可以存储多份数据；
4. znode 可以是临时节点，一旦创建这个 znode 的客户端与服务器失去联系，这个 znode 也将自动删除，Zookeeper 的客户端和服务器通信采用长连接方式，每个客户端和服务器通过心跳来保持连接，这个连接状态称为 session，如果 znode 是临时节点，这个 session 失效，znode 也就删除了；
5. znode 的目录名可以自动编号，如 App1 已经存在，再创建的话，将会自动命名为 App2；
6. 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 获取新的配置信息应用到系统中。

图 2. 配置管理结构图

 

队列管理

Zookeeper 可以处理两种类型的队列：

1. 当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到达，这种是同步队列。
2. 队列按照 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总数、临时节点总数。