zookeeper应用场景

1、基本思想：zookeeper的应用场景均可从其节点类型和watcher机制进行考虑。

2、应用场景：

a、统一命名服务：主要使用顺序节点进行。

b、集群管理：临时节点+wather机制

c、分布式日志收集：

d、master选举：

e、分布式锁：使用临时节点+监听机制

f、分布式屏障：使用临时节点+监听机制

3、具体应用：

（1）配置中心：数据发布/订阅，顾名思义就是发布者发布数据供订阅者进行数据订阅。从而动态获取数据（配置信息）实现数据（配置信息）的集中式管理和数据的动态更新。设计模式为，Push 模式和Pull 模式。

　　程序分布式的部署在不同的机器上，将程序的配置信息放在 zk 的 znode 下，当有配置发生改变时，也就是 znode 发生变化时，可以通过改变 zk 中某个目录节点的内容，利用 watcher 通知给各个客户端，从而更改配置。

 

　　数据（配置信息）特性：

　　a、数据量通常比较小

　　b、数据内容在运行时会发生动态更新

　　c、集群中各机器共享，配置一致如：机器列表信息、运行时开关配置、数据库配置信息等

 

　　基于 Zookeeper 的实现方式：

　　数据存储：将数据（配置信息）存储到 Zookeeper 上的一个数据节点。

　　数据获取：应用在启动初始化节点从 Zookeeper 数据节点读取数据，并在该节点上注册一个数据变更 Watcher。

　　数据变更：当变更数据时，更新 Zookeeper 对应节点数据，Zookeeper会将数据变更通知发到各客户端，客户端接到通知后重新读取变更后的数据即可。

 

（2）zk 的命名服务（文件系统）：命名服务是指通过指定的名字来获取资源或者服务的地址，利用 zk 创建一个全局的路径，这个路径就可以作为一个名字，指向集群中的集群，提供的服务的地址，或者一个远程的对象等等。

 

（3）集群管理：所谓集群管理无在乎两点：是否有机器退出和加入、选举 master。

　　对于第一点，所有机器约定在父目录下创建临时目录节点，然后监听父目录节点的子节点变化消息。一旦有机器挂掉，该机器与 zookeeper 的连接断开，其所创建的临时目录节点被删除，所有其他机器都收到通知：某个兄弟目录被删除，于是，所有人都知道：它上船了。新机器加入也是类似，所有机器收到通知：新兄弟目录加入，highcount 又有了。

　　对于第二点，我们稍微改变一下，所有机器创建临时顺序编号目录节点，每次选取编号最小的机器作为 master 就好。

 

（4）分布式锁：

　　有了 zookeeper 的一致性文件系统，锁的问题变得容易。锁服务可以分为两类，一个是保持独占，另一个是控制时序。

　　对于第一类，我们将 zookeeper 上的一个 znode 看作是一把锁，通过 createznode的方式来实现。所有客户端都去创建 /distribute_lock 节点，最终成功创建的那个客户端也即拥有了这把锁。用完删除掉自己创建的 distribute_lock 节点就释放出锁。

　　对于第二类， /distribute_lock 已经预先存在，所有客户端在它下面创建临时顺序编号目录节点，和选 master 一样，编号最小的获得锁，用完删除，依次方便。

 

（5）Zookeeper 队列管理：

　　两种类型的队列：

　　（1）同步队列，当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到达。

　　（2）队列按照 FIFO 方式进行入队和出队操作。第一类，在约定目录下创建临时目录节点，监听节点数目是否是我们要求的数目。第二类，和分布式锁服务中的控制时序场景基本原理一致，入列有编号，出列按编号。在特定的目录下创建 PERSISTENT_SEQUENTIAL 节点，创建成功时Watcher 通知等待的队列，队列删除序列号最小的节点用以消费。此场景下Zookeeper 的 znode 用于消息存储，znode 存储的数据就是消息队列中的消息内容，SEQUENTIAL 序列号就是消息的编号，按序取出即可。由于创建的节点是持久化的，所以不必担心队列消息的丢失问题。