Zookeeper官方文档学习

Zookeeper 3.5官方文档学习

介绍

Zookeeper是一个专为分布式应用提供的分布式的、开源的协调服务。它公开了一组简单的原语，分布式应用程序可以基于这些原语来实现用于同步，配置维护以及组和命名的更高级别的服务。它的设计易于编程，并使用了按照文件系统熟悉的目录树结构样式的数据模型。它以Java运行，并且具有Java和C的绑定。

Design Goals(设计目标)

Zookeeper是简单的。 它允许分布式进程通过共享的分级名称空间相互协调，组织方式类似于标准的文件系统。 name space（名称空间）由 znodes这种数据寄存器组成, 这些类似于文件和目录. 和传统的文件系统不同的是,zookeeper的数据保存在内存中, 而普通的文件系统存储在磁盘上. 这意味着zookeeper可以实现高吞吐量和低延迟

Zookeeper实施对高性能,高可用性,严格有序访问加以重视. 它的性能意味着它可以在大型的分布式系统中.

可靠性方面使得它不会由单点故障的情况存在. 严格的顺序意味着在客户端上可以实现复杂的同步原语

Zookeeper 也是分布式的,像它协调的分布式进程一样，ZooKeeper本身也可以在称为集合的主机上进行复制。

这些组成ZooKeeper服务的Servers 必须彼此了解.它们维护内存中的状态图像，以及持久存储中的事务日志和快照。只要大多数服务器可用，ZooKeeper服务将可用。

客户端连接到单个ZooKeeper服务器。客户端维护一个TCP连接，通过它发送请求，获取响应，获取监视事件并发送心跳。如果与服务器的TCP连接断开，则客户端将连接到其他服务器。

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

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

Data model and the hierarchical namespace(数据模型和分层名称空间)

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

ZooKeeper的层次命名空间:

Nodes and ephemeral nodes(节点和短暂节点:)

跟标准的文件系统不太一样, 每一个zookeeper名称空间中的节点都可以拥有与之相关的数据以及孩子节点.就好像有一个文件系统,这个文件系统可以允许一个文件又是一个目录.

ZooKeeper旨在存储协调数据：状态信息，配置，位置信息等，因此存储在每个节点上的数据通常很小，在字节到千字节范围内。

我们使用术语znode来明确表示我们正在谈论ZooKeeper数据节点。

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

ZooKeeper还具有短暂节点的概念。只要创建znode的会话处于活动状态，这些znode就存在。会话结束时，将删除znode。当您想实现[tbd]时，临时节点非常有用。

Conditional updates and watches (有条件的更新和监视)

Zookeeper支持监视的概念.客户端可以设置给znode设置监视. 一个监视将会被触发还有在znode变更的时候删除.当监视被触发时,客户端接收一个数据包,说明znode已经被修改 . 如果客户端和zookeeper servers的链接断开了,客户端就会接收到本地一个通知.

Guarantees（一致性的保证）

Zookeeper 是十分快速和简单的。因为它的目标，它将成为构建更复杂的服务的基础。例如同步， 它提供了一系列保证.

• 顺序一致性-来自客户端的更新将按照发送的顺序应用。
• 原子性-更新成功或失败。没有部分成功部分失败的可能性
• 单个系统映像-无论客户端连接到哪个服务器，客户端都将看到相同的服务视图。(单一性)
• 可靠性-应用更新后，此更新将一直持续到客户端覆盖更新为止。
• 实时性-Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息或者服务器失效的信息。

Simple API(简单的API)

zookeeper的其中一个设计目标就是提供一些很简单的编程接口给大家.So, 它只提供了这些操作:

• create: 在上文提到的层级空间中建立一个节点(层次空间可以类比成一棵树)
• delete: 删除一个节点
• exists: 判断一个节点是否存在
• get data: 读取一个节点的信息
• set data: 给一个节点设置一些信息
• get children: 获取一个节点的所有孩子节点
• sync: 等待数据传播(同步)

Implementation(实际操作)

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

Replicated Database 是一个包含了整个数据树的内存数据库. 它会更新数据到磁盘以保证可恢复性. 在将"写入"存储到内存数据库之前,会将其序列化到磁盘

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

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

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

uses(用途)

ZooKeeper的编程接口比较简单。但是，有了它，您可以实现更高阶的操作，例如同步原语，组成员资格，所有权等。

Performance(性能)

ZooKeeper被设计为具有高性能。是真的吗？ Yahoo!的ZooKeeper开发团队的结果。研究表明确实如此。 由于写入涉及同步所有服务器的状态，因此在读取次数超过写入次数的应用程序中，该性能特别高。 （对于协调服务，通常情况下，读取次数多于写入次数。）

Reliability(可靠性)

为了显示随着故障注入系统随时间变化的Zookeeper行为，我们运行了由7台机器组成的ZooKeeper服务。我们使用与以前相同的饱和度基准，但是这次我们将写入百分比保持在恒定的30％，这是我们预期工作量的保守比率。

该图有一些重要的观察结果。首先，如果followers 失败并迅速恢复，则ZooKeeper能够在失败的情况下维持高吞吐量。但是，也许更重要的是，leader选择算法允许系统恢复得足够快，以防止吞吐量大幅下降。根据我们的观察，ZooKeeper只需不到200毫秒即可选出新的leader。第三，随着followers 的恢复，ZooKeeper一旦开始处理请求就能够再次提高吞吐量。

Znode

每个Znode有自身信息，数据、长度、创建时间、修改时间。

Znode维护数据、ACL（access control list，访问控制列表）、时间戳等交换版本号等数据结构，它通过对这些数据的管理来让缓存生效并且令协调更新。每当Znode中的数据更新后版本号将增加。

读写操作

读写数据原子性，读就读取所有数据，写入时完全覆盖。Znode的ACL存储用户操作权限。

临时节点

和session相关，session结束，节点删除。(就是客户端和服务端断开连接之后,它就自动删除掉)

Zookeeper选举leader流程

1.选举Leader

2.同步数据

3.选举Leader过程中算法有很多，但要达到的选举标准是一致的

4.Leader要具有最高的zxid

5.集群中大多数的机器得到响应并follow选出的Leader

***半数机制（Paxos 协议）***：集群中半数以上机器存活，集群可用。所以 zookeeper 适合装在奇数台机器上

举例:如果有3台机器先后顺序启动zookeeper

第一台启动,此时只有它一个zookeeper节点,发包出去要跟别人选举,没人接收, 一直就是looking状态,zxid=1

第二台启动了, 它跟第一个节点开始通信,交换选举的包,但是两台机器都没有历史数据,所以zxid为2的第二台机器就赢了,但是此时它还没办法成为leader,因为需要>=半数的机器都投它的票才可以.

第三台启动了,它跟前两个节点通信,这个时候它的zxid=3,大于前两个,那么前两个机器就会选它作为leader,超过半数,成功当选. 牛逼

稍微懂一些了