Zookeeper介绍及实战（二）

三、Zookeeper特性概述

1）、Zookeeper 节点特性总结

1. 同一级节点 key 名称是唯一的

已存在/lock节点，再次创建会提示已经存在

2.创建节点时，必须要带上全路径

3.session 关闭，临时节点清除

4.自动创建顺序节点

 5.watch 机制，监听节点变化

事件监听机制类似于观察者模式，watch 流程是客户端向服务端某个节点路径上注册一个 watcher，同时客户端也会存储特定的 watcher，当节点数据或子节点发生变化时，服务端通知客户端，客户端进行回调处理。特别注意：监听事件被单次触发后，事件就失效了。

6.delete 命令只能一层一层删除。

提示：新版本可以通过 deleteall 命令递归删除。

2）、应用场景

ZooKeeper适用于存储和协同相关的关键数据，不适合用于大数据量存储。

有了上述众多节点特性，使得 zookeeper 能开发出不同的经典应用场景，比如：

• 注册中心
• 数据发布/订阅（常用于实现配置中心）
• 负载均衡
• 命名服务
• 分布式协调/通知
• 集群管理
• Master选举
• 分布式锁
• 分布式队列

3）、统一命名服务

在分布式环境下，经常需要对应用/服务进行统一命名，便于识别。

例如：IP不容易记住，而域名容易记住。

 

利用 ZooKeeper 顺序节点的特性，制作分布式的序列号生成器，或者叫 id 生成器。（分布式环境下使用作为数据库 id，另外一种是 UUID（缺点：没有规律）），ZooKeeper 可以生成有顺序的容易理解的同时支持分布式环境的编号。

/
└── /order
    ├── /order-date1-000000000000001
    ├── /order-date2-000000000000002
    ├── /order-date3-000000000000003
    ├── /order-date4-000000000000004
    └── /order-date5-000000000000005

4）、数据发布/订阅

数据发布/订阅的一个常见的场景是配置中心，发布者把数据发布到 ZooKeeper 的一个或一系列的节点上，供订阅者进行数据订阅，达到动态获取数据的目的。

配置信息一般有几个特点:

1. 数据量小的KV
2. 数据内容在运行时会发生动态变化
3. 集群机器共享，配置一致

ZooKeeper 采用的是推拉结合的方式。

1. 推: 服务端会推给注册了监控节点的客户端 Watcher 事件通知
2. 拉: 客户端获得通知后，然后主动到服务端拉取最新的数据

四、Zookeeper集群管理

1）、统一集群管理

分布式环境中，实时掌握每个节点的状态是必要的，可根据节点实时状态做出一些调整。

ZooKeeper可以实现实时监控节点状态变化：

• 可将节点信息写入ZooKeeper上的一个ZNode。
• 监听这个ZNode可获取它的实时状态变化。

2）、 负载均衡

在Zookeeper中记录每台服务器的访问数，让访问数最少的服务器去处理最新的客户端请求

 五、永久性Watch

在被触发之后，仍然保留，可以继续监听ZNode上的变更，是Zookeeper 3.6.0版本新增的功能

addWatch [-m mode] path

addWatch的作用是针对指定节点添加事件监听，支持两种模式

• PERSISTENT，持久化订阅，针对当前节点的修改和删除事件，以及当前节点的子节点的删除和新增事件。
• PERSISTENT_RECURSIVE，持久化递归订阅，在PERSISTENT的基础上，增加了子节点修改的事件触发，以及子节点的子节点的数据变化都会触发相关事件（满足递归订阅特性）