Zookeeper认识



1. ZooKeeper是一个用于分布式应用的开源分布式协调服务。它提供了简单的原语集合，分布式应用可在这些原语之上构建用于同步、配置维护、分组和命名的高层服务。ZooKeeper的设计使得编程容易，并且使用类似于广泛熟知的文件系统目录树结构的数据模型。它运行在Java环境中，但是有Java和C语言绑定。分布式协调服务是出了名的难得编写正确，很容易出现竞争条件和死锁之类的错误。ZooKeeper的动机是减轻为分布式应用开发协调服务的负担。

2. 设计目标

1. 简单

   ZooKeeper让分布式进程可通过共享的、与标准文件系统类似的分层名字空

相互协调。名字空间由数据寄存器（在ZooKeeper世界中称作znode）构成，这与文件和目录类似。与用于存储设备的典型文件系统不同的是，ZooKeeper在内存中保存数据，这让其可以达到高吞吐量和低延迟。ZooKeeper的实现很重视高性能、高可用性，以及严格的顺序访问。高性能意味着可将ZooKeeper用于大的分布式系统。可靠性使之可避免单点失败。严格的顺序访问使得客户端可以实现复杂的同步原语。

1. 自我复制

与它所协调的进程一样，ZooKeeper本身也会试图在一组主机间进行复制，这就是集群。这就是集群。组成ZooKeeper服务的各个服务器必须相互知道对方。它们在内存中维护状态和事务日志，还在永久存储中维护快照。只要大部分服务器可用，ZooKeeper服务就是可用的。客户端连接到单个ZooKeeper服务器。客户端维持一个TCP连接，通过这个连接发送请求、接收响应、获取观察事件，以及发送心跳。如果到服务器的TCP连接断开，客户端会连接到另一个服务器。

 

1. 顺序访问

ZooKeeper为每次更新设置一个反映所有ZooKeeper事务顺序的序号。并发操作可使用序号来实现更高层抽象，如同步原语。

1. 高速

在读操作为主的负载下特别快。ZooKeeper应用运行在成千上万台机器中，在读操作比写操作频繁，二者比例约为10:1的情况下，性能最好。

1. 数据模型和分层的名字空间

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

(6)节点和临时节点

与标准文件系统不同，ZooKeeper名字空间中的每个节点都可以有关联的数据以及子节点。这就像一个允许文件也是目录的文件系统。（ZooKeeper设计用于存储协调数据：状态信息、配置、位置信息等，所以通常存储在每个节点中的数据很小，在字节到千字节范围内）讨论ZooKeeper数据节点时，我们用术语znode来明确指示。Znode会维护一个stat结构体，其中包含数据和ACL的版本号与时间戳，以便于进行缓存验证和协调更新。每次修改znode数据时，版本号会增长。客户端获取数据的时候，也同时获取数据的版本。

对znode数据的读写操作是原子的。读取操作获取节点的所有数据，写入操作替换所有数据。节点的访问控制列表（ACL）控制可以进行操作的用户。ZooKeeper具有临时节点的概念。只要创建节点的会话是活动的，临时节点就存在。一旦会话终止，临时节点会被删除。临时节点对于实现tbd是很有用的。

1. 条件更新和观察

ZooKeeper支持观察的概念。客户端可以在znode上设置观察。观察将在znode修改时被触发和移除。观察被触发时客户端会收到一个数据包，指示znode已经被修改。如果与ZooKeeper服务之间的连接断开，客户端会收到一个本地通知。这可用于tbd。

1. 保证

   ZooKeeper非常高效和简单。基于其目标：成为构建如同步这样的更复杂服务的基础，ZooKeeper提供下述保证

1. 顺序一致性：客户端的更新将以请求发送的次序被应用。

2. 原子性：更新要么成功，要么失败，没有部分更新。

3. 单一系统镜像：无论连接到哪个服务器，客户端将看到一样的视图。

4. 可靠性：更新操作的结果将是持续的，直到客户端覆盖了更新。

5. 及时性：在某个时间范围内，客户端视图确保是最新的。

1. 简单的API

   ZooKeeper的设计目标之一是提供非常简单的编程接口。ZooKeeper仅支持这些操作

1. create:

2. delete:

3. exists:

4. get data:

5. set data:

6. get children:

7. sync:等待数据传播

1. 实现

下图显示了ZooKeeper服务的高层组件。除了请求处理器(Request Processor)之外，组成ZooKeeper服务的每个服务器拥有每个组件的自有拷贝。自我复制数据(replicated database)是一个包含整个数据树的内存数据库。更新会记录到磁盘中以便可以恢复，并且将写操作应用到内存数据库之前会先写入到磁盘。每个ZooKeeper服务器都为客户服务。客户端连接到一个服务器，提交请求。读请求由每个服务器数据库的本地拷贝进行服务。改变服务状态的请求和写请求由一致性协议处理。

作为一致性协议的一部分，客户端的所有写请求都被转发到单个服务器，也就是领导者。其他ZooKeeper服务器则是跟随者，它们接收来自领导者的建议，对传递的消息达成一致。消息层考虑了替换失败的领导者和跟随者与领导者同步的问题。

ZooKeeper使用定制的原子消息协议。因为消息层是原子的，ZooKeeper可保证本地拷贝不会发散（diverge）。收到写请求时，领导者计算写入操作后系统的状态，将其转换成一个捕获此状态的事务。

1. 使用

ZooKeeper的编程接口非常简单。但是，可将其用于实现高层顺序操作，如同步原语、组成员管理、所有者关系管理等。更多信息请参看tbd。

1. 性能

ZooKeeper被设计为高性能的。但它真的是高性能的吗？Yahoo研究中心的ZooKeeper开发团队证实了ZooKeeper的高性能，特别是在读操作比写操作多的应用中（见下图），因为写操作涉及在所有服务器间同步状态。（读操作比写操作多是协调服务的典型情况），上图是ZooKeeper 3.2在配置有两个2GHz Xeon处理器和两个SATA 15K RPM驱动器的服务器上运行时的吞吐率图形。一个驱动器配置为ZooKeeper日志专用设备。快照写入到操作系统驱动器。读写操作1KB的数据。“服务器数”指的是ZooKeeper集群的大小，即组成服务的服务器个数。大约30个其他服务器用于模拟客户端。ZooKeeper集群配置为不允许客户端连接到领导者。提示：3.2版的读写性能是3.1版的2倍。

Benchmarks也表明ZooKeeper是可靠的。下图（第10节的图）显示了ZooKeeper在各种失败情况下的反应。图中标记的各个事件是：

1．跟随者失败和恢复

2．另一个跟随者失败和恢复

3．领导者失败

4．两个跟随者失败和恢复

5．另一个领导者失败

1. 可靠性

   为揭示在有失败注入时系统的行为，我们在一个由7台机器组成的ZooKeeper服务上运行和先前一样的benchmark测试，但是让写操作的百分比固定为30%，这是预期负载比例的保守估计。此图有几处值得仔细观察。首先，如果跟随者失败后快速恢复，则ZooKeeper可以维持高吞吐率。但更重要的是，领导者选举算法让系统可以足够快地恢复，以阻止吞吐率有实质性的下降。据我们观察，ZooKeeper选举一个新的领导者的时间小于200ms。第三，一旦跟随者恢复并且开始处理请求，ZooKeeper可以恢复高吞吐率。

   （13）ZooKeeper工程

ZooKeeper已经在很多工业应用中成功使用。Yahoo!在Yahoo! Message Broker中使用ZooKeeper作为协调和故障恢复服务。Yahoo! Message Broker是一个高度扩展的发布-订阅系统，管理着成千上万个需要拷贝和数据传递的话题。Yahoo!的很多广告系统也使用ZooKeeper来实现可靠服务。

二、ZooKeeper理解

1.服务治理框架：Dubbo。注册中心：Zookeeper集群

2.解决分布式问题的一个工具

3. ZooKeeper是Apache的一个java项目，属于Hadoop系统，扮演管理员的角色

4.Zookeeper作用

（1）配置管理

这个好理解。分布式系统都有好多机器，比如我在搭建hadoop的HDFS的时候，需要在一个主机器上（Master节点）配置好HDFS需要的各种配置文件，然后通过scp命令把这些配置文件拷贝到其他节点上，这样各个机器拿到的配置信息是一致的，才能成功运行起来HDFS服务。Zookeeper提供了这样的一种服务：一种集中管理配置的方法，我们在这个集中的地方修改了配置，所有对这个配置感兴趣的都可以获得变更。这样就省去手动拷贝配置了，还保证了可靠和一致性。

1. 名字服务

   这个可以简单理解为一个电话薄，电话号码不好记，但是人名好记，要打谁的电话，直接查人名就好了。分布式环境下，经常需要对应用/服务进行统一命名，便于识别不同服务；类似于域名与ip之间对应关系，域名容易记住；通过名称来获取资源或服务的地址，提供者等信息

2. 分布式锁

   碰到分布二字貌似就难理解了，其实很简单。单机程序的各个进程需要对互斥资源进行访问时需要加锁，那分布式程序分布在各个主机上的进程对互斥资源进行访问时也需要加锁。很多分布式系统有多个可服务的窗口，但是在某个时刻只让一个服务去干活，当这台服务出问题的时候锁释放，立即fail over到另外的服务。这在很多分布式系统中都是这么做，这种设计有一个更好听的名字叫Leader Election(leader选举)。举个通俗点的例子，比如银行取钱，有多个窗口，但是呢对你来说，只能有一个窗口对你服务，如果正在对你服务的窗口的柜员突然有急事走了，那咋办？找大堂经理（zookeeper）!大堂经理指定另外的一个窗口继续为你服务！

3. 集群管理

   在分布式的集群中，经常会由于各种原因，比如硬件故障，软件故障，网络问题，有些节点会进进出出。有新的节点加入进来，也有老的节点退出集群。这个时候，集群中有些机器（比如Master节点）需要感知到这种变化，然后根据这种变化做出对应的决策。我已经知道HDFS中namenode是通过datanode的心跳机制来实现上述感知的，那么我们可以先假设Zookeeper其实也是实现了类似心跳机制的功能吧！

4. Zookeeper的特点

1. 最终一致性：为客户端展示同一视图，这是zookeeper最重要的功能。

2. 可靠性：消息被到一台服务器接受，那么它将被所有的服务器接受。

3. 实时性：Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。

4. 等待无关性：慢的或者失效的client不干预快速的client的请求。

5. 原子性：更新只能成功或者失败，没有中间状态。

6. 顺序性：所有Server，同一消息发布顺序一致。