ZooKeeper_10_ZooKeeper典型应用场景

ZooKeeper典型应用场景

了解就好，了解就好，如果你缺少实际项目经验，有些可能会不是很明白..

1. 数据发布/订阅

数据发布/订阅系统，即所谓的配置中心，顾名思义就是发布者将数据发布到ZooKeeper的一个或一系列节点上，

供订阅者进行数据订阅，进而达到动态获取数据的目的，实现配置信息的集中式管理和数据的动态更新。

推模式：

服务端主动将数据更新发送到所有订阅的客户端。

拉模式：

客户端主动发起请求来获取最新数据。

ZooKeeper采用推拉结合方式：

客户端向服务端注册自己需要关注的节点，一旦该节点的数据发生变更，那么服务端就会向相应的客户端发送Watcher事件通知，客户端接收到消息通知之后，需要主动到服务端获取最新的数据

2. 负载均衡

负载均衡这个我没太看明白，仅作了解吧...

3. 命名服务

在分布式系统中，被命名的实体通常可以是集群中的机器，提供的服务地址或远程对象等..

较为常见的就是一些分布式服务框架(PRC等)中的服务地址列表，通过使用命名服务，客户端应用能够根据指定名字来获取资源的实体、服务地址和提供者的信息等。

上面的描述让我想到了，服务化体系中的服务注册与服务治理。

4. 分布式协作/通知

分布式协调/通知机制是分布式系统中不可缺少的一个环节，是将不同的分布式组件有机结合起来的关键所在。

ZooKeeper中特有的watcher注册与异步通知机制，能够很好地实现分布式环境下不同机器，甚至是不同系统之间的协调与通知，

从而可以大大减少系统之间的耦合性，而且能够显著提高系统的可扩展性。

通常的做法是，不同的客户端都对ZooKeeper上同一个数据节点进行Watcher注册，监听数据节点的变化，如果数据节点发生变化，

那么所有订阅的客户端都能够收到相应的Watcher通知，并作出相应的处理。

5. 集群管理

所谓集群管理，包括集群监控与集群控制两大块。

集群监控：侧重对集群运行时状态的收集

集群控制：侧重对集群操作与控制

ZooKeeper具有以下两大特性：

a. 客户端如果对ZooKeeper的一个数据节点注册Watcher监听，那么当该数据节点的内容或是其子节点列表发生变更时，ZooKeeper服务器就会向订阅的客户端发送变更通知。

b. 对在ZooKeeper上创建的临时节点，一旦客户端与服务端之间的会话失效，那么该临时节点也就被自动清除。

6. Master选举

Master选举是一个在分布式系统中非常常见的应用场景。

实际场景中，往往也需要在这些不同机器上的独立系统单元中选出一个所谓的老大"Master"。

(在分布式系统中，Master往往用来协调集群中其他操作单元，具有对分布式系统状态变更的决定权。)

抛开原书中的繁文缛节，直接看重点

Master选举过程：

利用ZooKeeper的强一致性，能够很好地保证在分布式高并发情况下节点的创建，一定能保证全局唯一性，即ZooKeeper将会保证客户端无法创建一个已经存在的数据节点。

也就是说，如果同时有多个客户端请求创建同一个节点，那么最终一定只有一个客户端的请求能够创建成功。

利用这个特性，就能很容易的在分布式环境中进行Master选举了。

7. 分布式锁

(暂了解，后续有空研究)

分布式锁是控制分布式系统之间同步访问共享资源的一种方式。

8. 分布式队列

ActiveMQ、Kafka等消息中间件