ZooKeeper架构

ZooKeeper是一个分布式应用程序协调服务，是Google的Chubby一个开源的实现，是众多开源分布式应用的核心组件之一。它是一个为分布式应用提供配置维护、域名服务、分布式同步、分布式锁、服务注册等服务。ZooKeeper具备以下几个特性。

1 简单易用

ZooKeeper以分布式方式协调各个应用程序，它提供一个共享的分级的命名空间，这个命名空间类似于一个标准的Linux文件系统。命名空间由称之为znode的数据注册者组成，它的语法与文件和目录的相似。不像为存储而设计的典型文件系统，ZooKeeper数据是保存在内存中，这样使得ZooKeeper能够实现高吞吐和低延迟。具体数据模型，见下图。

2 重复性

如ZooKeeper协助的分布式处理一样，它本身就是在一个被称为ensemble的集合主机之中进行重复的。那些组成ZooKeeper服务的服务器（Servers）必须彼此了解。就是这些服务器维持着内存的状态印象，伴随着事务日志和持久化存储的快照（Snapshots）。只要主要的服务器有效存在，ZooKeeper服务就会提供可能的服务。当客户端连接到一个单一的ZooKeeper服务器时，客户端维持着一个TCP连接。通过这个TCP连接，客户端可以发送请求，获得响应答复，得到观察者监听事件，发送心态状态信息。如果这个TCP连接中断，客户端将连接到不同的机器。

3 有序性

ZooKeeper以一个数字标记任何一次更新，这个数字反应了所有ZooKeeper事务的有序性。随后，操作能够使用这个有序性实现更高级的抽象，比如同步原生态操作。

4 性能高效

在于只读的工作量中，ZooKeeper是特别高效的。ZooKeeper应用程序可以运行在成千上万的机器上，当一般的读大于写的操作时，ZooKeeper表现出最佳的性能，尤其是读写比例达到10:1.下面一个性能测试报告，见下图。

5 可靠 性

ZooKeeper支持失败容错，ZooKeeper集群是由一个leader和剩余的follower组成，一旦leader失效，follower会根据leader选举算法选举出新的leader。为了呈现ZooKeeper的可靠性，我们运行一个有7个节点组成的ZooKeeper服务。测试结果图如下所示：

从上图表可以知道，如果follower失效和快速恢复时，ZooKeeper能够维持一个高吞吐量。更重要的是，leader选择算法允许系统进快地复原，以便防止吞吐量致命地下降。从上图可知，ZooKeeper至少要200ms推举出一个新的leader。随着follower恢复正常状态，ZooKeeper不断提高它处理请求的能力。下图是应用程序进程、客户端库（Client Library）与ZooKeeper Ensemble的交互模型。

---

---

---

迎春节，猴年财源滚滚！

欢迎关注我的微信公众号