ZooKeeper简介与项目中应用

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。它被设计成易于编程，并且使用了一种以熟悉的文件系统目录树结构为样式的数据模型。它运行在Java中，绑定了Java和C语言。总所周知，服务协调是出了名的很难做。它们特别容易出错，例如竞争条件和死锁。ZooKeeper背后的动机是减轻分布式应用程序从零开始实现协调服务的责任。

设计目标：

简易性：ZooKeeper允许分布式进程通过共享的分层名称空间相互协调，该命名空间的组织方式类似于标准文件系统。名称空间由数据寄存器（Zookeeper中称为znode）组成，它们类似于文件和目录。与设计用于存储的典型文件系统不同，ZooKeeper数据保留在内存中，这意味着ZooKeeper可以实现高吞吐量和低延迟数。

ZooKeeper实施对高性能，高可用性，严格排序的访问给予了重视。ZooKeeper的性能方面意味着它可以在大型的分布式系统中使用。可靠性方面使它不会成为单点故障。严格排序意味着可以在客户端上实现复杂的同步原语。（所谓原语，一般是指由若干条指令组成的程序段，用来实现某个特定功能，在执行过程中不可被中断。）

复制性：像它协调的分布式进程一样，ZooKeeper本身也可以在称为集合的一组主机上进行复制。组成ZooKeeper服务的服务器都必须彼此了解。它们维护内存中的状态图像，以及持久存储中的事务日志和快照。只要大多数服务器可用，ZooKeeper服务将可用。客户端连接到单个ZooKeeper服务器。客户端维护一个TCP连接，通过该连接发送请求，获取响应，获取监视事件并发送心跳。如果与服务器的TCP连接断开，则客户端将连接到其他服务器。如下图所示：

有序性：ZooKeeper用一个反映所有ZooKeeper事务顺序的数字标记每个更新。后续操作可以使用该命令来实现更高级别的抽象，例如同步原语。

高效性：在“读取为主”的工作负载中，它特别快。ZooKeeper应用程序可在数千台计算机上运行，并且在读取比写入更常见的情况下以10：1的比率运行时效果最佳。

数据模型和分层名称空间：

ZooKeeper提供的名称空间与标准文件系统的名称空间非常相似。名称是由斜杠（/）分隔的一系列路径元素。ZooKeeper命名空间中的每个节点都由路径标识。模型图如下所示：

 节点与临时节点：

与标准文件系统不同，ZooKeeper命名空间中的每个节点都可以具有与其关联的数据以及子节点。就像拥有一个文件系统一样，该文件系统也允许文件成为目录。（ZooKeeper旨在存储协调数据：状态信息，配置，位置信息等，因此存储在每个节点上的数据通常很小，在几字节到千字节范围内。）我们使用术语znode来明确表示在谈论ZooKeeper数据节点。

Znodes维护一个统计信息结构，其中包括用于数据更改，ACL更改和时间戳的版本号，以允许进行缓存验证和协调更新。znode的数据每次更改时，版本号都会增加。例如，每当客户端检索数据时，它也接收数据的版本。

原子地读取和写入存储在名称空间中每个znode上的数据。读取将获取与znode关联的所有数据字节，而写入将替换所有数据。每个节点都有一个访问控制列表（ACL），用于限制谁可以执行操作。

ZooKeeper还具有临时节点的概念。只要创建znode的会话处于活动状态，这些znode就会存在。会话结束时，将删除znode。

选择性更新和监听：

ZooKeeper支持监听的概念。客户端可以在znode上设置监听。znode更改时，将触发并删除监听。触发监听后，客户端会收到一个数据包，说明znode已更改。如果客户端和其中一个ZooKeeper服务器之间的连接断开，则客户端将收到本地通知。

3.6.0中的新增功能：客户端还可以在znode上设置永久的，递归的监听，这些监听在被触发时不会被删除，并且会以递归方式触发已注册znode以及所有子znode的更改。

保障：

ZooKeeper非常快速且使用非常简单。但是，由于其目标是作为构建更复杂的服务（例如同步）的基础，因此它提供了一组保障。这些是：

1. 顺序一致性：-来自客户端的更新将按照发送的顺序应用。
2. 原子性：更新成功或失败。不会出现部分更新成功部分失败这种情况
3. 单个系统映像：无论客户端连接到哪个服务器，客户端都将看到相同的服务视图。也就是说，即使客户端故障转移到具有相同会话的其他服务器，客户端也永远不会看到系统的较旧视图。
4. 可靠性：一旦应用了更新，该更新将一直持续到客户端覆盖更新为止。
5. 及时性：确保系统的客户视图在特定时间范围内是最新的。

实现：

下图展示了ZooKeeper服务的高级组件。除请求处理器外，构成ZooKeeper服务的每个服务器都复制其自己的每个组件副本。

复制的数据库是包含整个数据树的内存数据库。更新被记录到磁盘以确保可恢复性，并且在将写入应用于内存数据库之前将写入序列化到磁盘。

每个ZooKeeper服务器都为客户端提供服务。客户端仅连接到一台服务器即可提交请求。读取请求从每个服务器数据库的本地副本提供服务。更改服务状态的请求（写请求）由协商协议处理。

作为协商协议的一部分，来自客户端的所有写请求都转发到称为leader的单个服务器。其余的ZooKeeper服务器（称为followers）从leader接收消息建议并同意消息传递。消息传递层负责替换出现故障的leader，并将followers与leader同步。

ZooKeeper使用自定义的原子消息传递协议。由于消息传递层是原子层，因此ZooKeeper可以保证本地副本永远不会发散。领导者收到写请求时，它将计算要应用写操作时系统的状态，并将其转换为捕获该新状态的事务。

用途：

ZooKeeper的编程接口相对简单。但是，使用它可以实现更高级的操作，例如同步原语，组成员关系，所有权等。如下为几种zookeeper的几种应用场景：分布式锁，分布式通知/协调，集群管理，Master选举，分布式队列等，后续我们会使用案例来讲述这几种用用场景。