ZooKeeper介绍、分析、理解-问答-阿里云开发者社区-阿里云

一、ZooKeeper是什么？

ZooKeeper is a distributed, open-source coordination service for distributed applications.
Zookeeper 作为一个分布式的服务框架，主要用来解决分布式集群中应用系统的一致性问题。
它能提供基于类似于文件系统的目录节点树方式的数据存储。
但是 Zookeeper 并不是用来专门存储数据的，它的作用主要是用来维护和监控你存储的数据的状态变化。
通过监控这些数据状态的变化，从而可以达到基于数据的集群管理。
ZooKeeper是一个开源的分布式的，为分布式应用提供协调服务的Apache项目。ZooKeeper提供一个简单的原语集合，以便于分布式应用可以在它之上构建更高层次的同步服务。ZooKeeper的设计非常易于编程，它使用的是类似于文件系统那样的树形数据结构。

(A、我不明白，它像标准的文件系统那样设计，那么ZooKeeper是一个文件系统吗？它不就是一个管理若干server的service吗？它为什么要这样的设计？？)

想正确的实现一个协作服务是出了名的难，最常见的错误就是竞争条件和死锁。ZooKeeper的动机就是解放那些从事开发分布式应用的程序员，让他们避免从零开始实现协作服务。(B、ZooKeeper数据是放到内存中的，这样的设计对分布式系统有什么帮助？)

HBase中会默认使用ZooKeeper。

图示1 ZooKeeper的数据结构
ZooKeeper数据结构的特点：
每个子目录项如 NameService 都被称作为 znode，这个 znode 是被它所在的路径唯一标识，如 Server1 这个 znode 的标识为 /NameService/Server1；
znode 可以有子节点目录，并且每个 znode 可以存储数据，注意 EPHEMERAL 类型的目录节点不能有子节点目录(因为它是临时节点)；
znode 是有版本的，每个 znode 中存储的数据可以有多个版本，也就是一个访问路径中可以存储多份数据
znode 可以是临时节点，一旦创建这个 znode 的客户端与服务器失去联系，这个 znode 也将自动删除，Zookeeper 的客户端和服务器通信采用长连接方式，每个客户端和服务器通过心跳来保持连接，这个连接状态称为 session，如果 znode 是临时节点，这个 session 失效，znode 也就删除了
znode 的目录名可以自动编号，如 App1 已经存在，再创建的话，将会自动命名为 App2
znode 可以被监控，包括这个目录节点中存储的数据的修改，子节点目录的变化等，一旦变化可以通知设置监控的客户端，这个是 Zookeeper 的核心特性，Zookeeper 的很多功能都是基于这个特性实现的，后面在典型的应用场景中会有实例介绍

二、设计目标
2.1 ZooKeeper is simple. 简单

ZooKeeper 维护着一个hierarchal的名字空间(整个文件系统所共享的)，这个名字空间的组织形式很像标准文件系统(C、哪种文件系统？HDFS还是EXT3还是FAT还是NTFS？ EXT3文件系统)。分布式的进程可以通过操作这个共享的名字空间来协作。 ZooKeeper的名字空间由称作znodes的data register组成，znodes和文件，路径很像(D、znodes到底是和文件相似还是和路径相似？？？翻译的害死人阿！)。但是不同于典型的文件系统，ZooKeeper的数据都存放在内存中，这意味着ZooKeeper 的吞吐量会很高，同时latency会比较低。(E、这样设计对我们整体的分布式系统有什么益处？你想想，Hadoop在shuffling期间的快速排序也是将数据放入内存中，但我们的内存空间是有限的，大会都把数据放到内存中，对系统的整体性能造成的影响有多大？？？)

ZooKeeper的实现更重视high performance, highly available, strictly ordered access. 也就是说ZooKeeper要能够用于大型的分布式系统，同时要避免出现单点故障，还能够通过自身的有序性以便让client实现复杂的同步原语。

2.2 ZooKeeper is replicated. 可复制

分布式的系统不可避免的都会有备份。

ZooKeeper Service

组成ZooKeeper service的所有server都必须知道其他server的存在。这些server在内存中维护着一个状态的镜像(或许就像Hadoop的NameNode一样，本身体积不大但作用很大)，还有持久存储的 transaction logs和快照(在硬盘上)。只要集群中多数server可访问，那么ZooKeeper服务就可用(思考：一个集群中会有各种各样的server，生产的，营销的，财务的，人力的，搜索引擎的等等，而且每个server都有自己的副本，跑了这么多的server怎么管理？我们可以搞一个管理server的service，那么这个重任就交给了ZooKeeper)。

Clients 会连接到某一个ZooKeeper server上。client维护一个TCP连接，通过TCP连接， client发送请求，得到response，watch event，还有发送心跳。如果连接到某个server的TCP连接断了，client将会连接到另一个server上。

2.3 ZooKeeper is ordered. 有序

ZooKeeper给每个update操作都附上了stamp，通过stamp来反映所有transaction的顺序。

2.4 ZooKeeper is fast. 高速

ZooKeeper很快，尤其是在读操作占主导地位的服务中(靠，为什么快？因为你在内存中跑能不快么？)。ZooKeeper应用可以跑在上千台机器上，当读写操作的比例为10：1时，性能达到最佳。

三、 Data model and the hierarchical namespace
ZooKeeper提供的名字空间非常像一个标准文件系统。

name的形式和Unix的路径一样，由slash隔开。ZooKeeper的名字空间中的每个node都有一个path指定。（EXT3典型的树形结构）

ZooKeeper’s Hierarchical Namespace

四、 Nodes and ephemeral nodes 结点和临时结点
ZooKeeper namespace的一个特点是：每个znode都可以存放数据或者连接child(F、这里的child是个什么概念？)，就好像一个文件系统的文件同时可以是路径一样。

(ZooKeeper 被设计为用来存储coordination data：包括status information，configuration，location information等等，所以每个znode存放的数据通常是很小的，数量级在KB范畴)

Znode维护着一个stat结构，包括data changes，ACL changes的version number，还有timestamp。这样可以检查cache的有效性以及coordinated updates。每当一个znode的data改变了，version number就会增加。例如，只要一个client取了data，那么它同时也会受到这个data的version。

对每个znode中存储的data的读写操作都是原子的。读操作会拿到这个znode所关联的所有data bytes。而写操作会覆盖掉所有的data。每个node都有一个Access Control List来限制谁能做什么操作。

ZooKeeper还有临时node(ephemeral node)的概念。这种ephemeral znode只存在于创建该znode的session中。session结束了，这个znode也就被删除了。

五、 Conditional updates and watches
ZooKeeper 支持watches。Clients可以在某个znode上设置一个watch。这个znode发生的任何变化都会触发这个watch，随后watch被删除。当watch被触发时，client会接收到一个packet说该znode已经被修改了。如果client和ZooKeeper server的连接断了，那么client会接收到一个local notification。

六、 Guarantees
ZooKeeper非常快，用起来也很简单。由于它的目标是作为更复杂的服务的基础架构，所以它提供了一系列的guarantee，包括：

Sequential Consistency序列一致性：从同一个client来的updates动作会按照这些updates发送时的顺序执行。
Atomicity原子性：Updates要么成功，要么失败。不会有部分成功的结果。
Single System Image单系统镜像：无论client连接到了哪个server，只会看到相同的view。
Reliability可靠性：只要一个update成功执行了，那么在一个client覆盖此次update之前，该update的结果一直有效。
Timeliness时效性：保证clients在一个确定的时限内能够观察到最新的系统数据。

理论的东西毕竟是理论的东西，你自己不用它是无法深刻理解的