【zookeeper】ZooKeeper的特点及应用场景

ZooKeeper 的特点/设计目标

ZooKeeper（动物园管理员） ，顾名思义，是用来管理Hadoop（大象）、Hive（蜜蜂）、Pig（小猪）的管理员，同时Apache HBase、Apache Solr等众多项目中都采用了ZooKeeper。作为一个集群提供数据一致的分布式协调服务，它最好的方式就是在整个集群中的各服务节点进行数据的复制和同步。

数据复制的好处：

• 容错：一个节点出错，不至于让整个集群无法提供服务

• 扩展性：通过增加服务器节点能提高 ZooKeeper 系统的负载能力，把负载分布到多个节点上

• 高性能：客户端可访问本地 ZooKeeper 节点或者访问就近的节点，依次提高用户的访问速度

设计目的

• 一致性：client不论连接到哪个Server，展示给它都是同一个视图，这是zookeeper最重要的性能。
• 可靠性：具有简单、健壮、良好的性能，如果消息被到一台服务器接受，那么它将被所有的服务器接受。
• 实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。但由于网络延时等原因，Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。
• 等待无关（wait-free）：慢的或者失效的client不得干预快速的client的请求，使得每个client都能有效的等待。
• 原子性：更新只能成功或者失败，没有中间状态。
• 顺序性：包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有Server上消息a都将在消息b前被发布；偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面。

ZooKeeper 典型应用场景

命名服务

命名服务是分布式系统中较为常见的一类场景，分布式系统中，被命名的实体通常可以是集群中的机器、提供的服务地址或远程对象等，通过命名服务，客户端可以根据指定名字来获取资源的实体、服务地址和提供者的信息。Zookeeper 可以帮助应用系统通过资源引用的方式来实现对资源的定位和使用，广义上的命名服务的资源定位都不是真正意义上的实体资源， 在分布式环境中，上层应用仅仅需要一个全局唯一的名字。Zookeeper 可以实现一套分布式全局唯一 ID 的分配机制。如下，ZooKeeper节点生产全局唯一ID的示意图：

说明，对于多个任务列表的主键，使用ZooKeeper生成唯一ID的基本步骤：

• 所有客户端都会根据自己的任务类型，在指定类型的任务下面通过调用create（）接口来创建一个顺序节点，例如创建“job-”节点。
• 节点创建完毕后，create（）接口会返回一个完整的节点名，例如“job-0000000001”。
• 客户端拿到这个返回值后，拼接上 type 类型，例如“type2-job-0000000001”，这就可以作为一个全局唯一的ID了。

在ZooKeeper中，每一个数据节点都能够维护一份子节点的顺序顺列，当客户端对其创建多个顺序子节点的时候 ZooKeeper 会自动以后缀的形式在其子节点上添加一个序号，在这个场景中就是利用了 ZooKeeper的这个特性。

配置管理

程序总是需要配置的，如果程序分散部署在多台机器上，要逐个改变配置就变得困难。现在把这些配置全部放到 ZooKeeper 上去，保存在 ZooKeeper 的某个目录节点中，然后所有相关应用程序对这个目录节点进行监听，一旦配置信息发生变化，每个应用程序就会收到 ZooKeeper 的通知，然后从 ZooKeeper 获取新的配置信息应用到系统中就可以了，这样就实现了配置信息的集中式管理和数据的动态更新。

集群管理

所谓集群管理无在乎两点：是否有服务器退出或者加入、选举master。
　　前者侧重对集群运行时状态的收集，所有机器约定在父目录 GroupMembers 下创建临时目录节点，然后监听父目录 节点的子节点变化消息。一旦有机器挂掉，该机器与 ZooKeeper 的连接断开，其所创建的临时目录节点被删除，所有其他机器都收到通知：某个服务器目录被删除，于是，所有人都知道：有服务器挂了。新机器加入也是类似，所有机器收到通知：新服务器目录加入，又多了个新服务器。
　　后者则是对集群进行操作与控制，我们稍微改变一下，所有机器创建临时顺序编号目录节点，每次选取编号最小的机器作为 master 就好。当然，这只是其中的一种策略而已，选举策略完全可以由管理员自己制定。

Zookeeper的两大特性：

• 客户端如果对Zookeeper的数据节点注册Watcher监听，那么当该数据节点的内容或是其子节点列表发生变化时，Zookeeper服务器就会向订阅的客户端发送变更通知。
• 对在Zookeeper上创建的临时节点，一旦客户端与服务器之间的会话失效，那么临时节点也会被自动删除利用其两大特性，可以实现集群机器存活监控系统，若监控系统在/clusterServers节点上注册一个 Watcher监听，那么如果有进行动态添加机器的操作，就会在/clusterServers节点下创建一个临时节点类似：/clusterServers/[Hostname]，这样，监控系统就能够实时监测机器的变动情况。

分布式锁

分布式锁是控制分布式系统之间同步访问共享资源的一种方式。如果不同的系统或是同一个系统的不同主机之间共享了一个或多个资源，那么访问这些资源的时候，往往需要通过一些互斥手动段来防止彼此之间的干扰，以保证一致性，在这种情况下，就需要使用分布式锁了。有了 ZooKeeper 的一致性文件系统，锁的问题变得容易。 锁服务可以分为两三类

• 一个是写锁（Exclusive Locks，简称 X 锁），对写加锁，保持独占，或者叫做排它锁，独占锁
• 一个是读锁（Shared Locks，简称S锁），对读加锁，可共享访问，释放锁之后才可进行事务操作，也叫共享锁
• 一个是控制时序，叫时序锁

对于第一类，我们将 ZooKeeper 上的一个 znode 看作是一把锁，通过 createznode 的方式来 实现。所有客户端都去创建 /distribute_lock 节点，最终成功创建的那个客户端也即拥有了 这把锁。用完删除掉自己创建的 distribute_lock 节点就释放出锁
　　对于第二类， /distribute_lock 已经预先存在，所有客户端在它下面创建临时顺序编号目录 节点，和选 master 一样，编号最小的获得锁，用完删除，依次有序。
　　

队列管理

两种类型的队列：

• 同步队列：当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到达（Barrier模型）。
• 先进先出队列：队列按照 FIFO 方式进行入队和出队操作（FIFO先入先出队列模型）。

第一类，在约定目录下创建临时目录节点，监听节点数目是否是我们要求的数目。
第二类，和分布式锁服务中的控制时序场景基本原理一致，入列有编号，出列按编号。 同步队列的流程图：

更多关于zookeeper的知识分享，请前往博客主页。编写过程中，能力有限难免出现差错，敬请指正