Zookeeper深入浅出之快速入门实例

what is Zookeeper?

• zk分布式服务框架是apache hadoop的一个子项目，主要用于分布式当中，如集群管理，统一命名服务，分布式锁，分布式消息队列，分布式配置管理等。

比如：

【分布式配置管理】

发布者发布数据/配置信息到ZK节点上，供订阅者动态订阅数据，实现配置信息的集中式管理和动态更新。

【命名服务】

在分布式应用当中，我们要保证命名的唯一性，可以通过ZK的create node api很容易的创建一个全局唯一的PATH作为name service。

【分布式通知和协调】

如果不同系统之间对ZK的同一个ZNODE节点进行注册，监听ZNODE的变化（包括ZNODE及其子节点），其中一个系统UPDATE了ZNODE，那么另一个系统能够收到通知并作相应的处理。

其实是利用到了ZK特有的watch注册和异步通知机制，实现分布式环境下不同系统的通知和协调，实现对数据变更的实时处理。

• 现在很多分布式计算需要依赖ZK，比如hadoop，storm，hbase等。

比如，对于Storm而言：

消息先发送到nimbus(master)，然后由ZK分发到supervisor(slave)上，可见ZK保存了STORM集群和作业的信息，并负责nimbus和supervisor的通信

• 一句话，就是因为ZK在分布式中的特性，可以方便我们在分布式开发解决一些困难，因此我们需要深入学习下ZK。

ZK的体系结构

先看图：

1. ZK中有很多Server，然后其中有一台是leader。

2. Server端具有fast fail特性，也就是说如果leader挂了，可以快速选举出新的leader，不存在单点故障。

3. 非leader节点，只要超过半数的节点正常就不影响对外提供服务，非常健壮。

4. 客户端提交请求，首先会提交到Server leader，然后由leader广播到其他的server.

• ZK可以存储协调数据，如状态、配置等信息，每个节点存储的数据量很小，KB级别。

• ZK NODE类似文件系统的目录树型结构

• 每个节点具有与之对应的数据内容，同时也可以具有子节点

• 有四种节点，临时节点是不可以有子节点的

• 节点维护一个状态stat结构（包括数据变化的版本号，ACL变化，时间戳）

• 每当节点数据内容改变时，多一个版本号【这一点和HBASE比较类似】，CLIENT在获取数据的同时也会获取版本号，节点的数据内容以原子方式读写。

• 节点具有一个访问控制列表Access Control List : ACL 来约束访问操作，即具有权限控制。

ZK的特性：watch机制

• 当ZK的节点数据变化时，会触发watch事件，即ZK对NODE的增，删，改，查都会触发监听。

• watch是一次性触发机制，但watch监视的数据发生变化时，通知设置了该watch的client，即watcher，也就是说，如果我们设置了watch事件，触发后，如果我们不继续watch该事件，将不再监视。

• watch事件异步发送至观察者，watch事件的设置是有延迟的。

• client监视一个节点，总是先获取watch事件，在发现节点的数据变化。

ZK安装、命令行测试实例

STEP1：认识ZK的启动脚本、配置文件

注意2点：

第一，client与该server连接的port

第二，dataDir指出znode存储的路径、该路径下还会存放server的PID文件

zkServer.sh是start/stop server的脚本，并且还可以查看状态信息。

zkCli.sh是客户端连接server:port的脚本。

STEP2：在单机上做一个伪分布式的ZK集群

先看配置文件信息：

类似的，提供zoo2.cfg,zoo3.cfg配置文件。

server.X=IP:PORT1:PORT2的意思是这样的：

在ZK中server是有编号的，而X就表示该server的序号。IP是server的地址，PORT1表示的是该server与leader通信过程中采用的端口，PORT2表示的是如果leader重新选取的话，采用PORT2端口进行通信。

看dataDir的情况：

需要注意的是，每个Server都需要提供一个myid文件来表示自己在ZK的序号，与配置文件中对应。

启动多个ZK SERVER实例：

查看ZK状态信息：

客户端连接SERVER进行操作：

到这里，ZK的基本介绍和入门使用就结束了，GOOD NIGHT~

本文转自zfz_linux_boy 51CTO博客，原文链接：http://blog.51cto.com/zhangfengzhe/1837667，如需转载请自行联系原作者