ZooKeeper系列（一）

文章来源：http://blog.csdn.net/qq_24908345/article/details/52786087

Zookeeper产生的背景

ZooKeeper---译名为“动物园管理员”。动物园里当然有好多的动物，游客可以根据动物园提供的向导图到不同的场馆观赏各种类型的动物，而不是像走在原始丛林里，心惊胆颤的被动 物所观赏。为了让各种不同的动物呆在它们应该呆的地方，而不是相互串门，或是相互厮杀，就需要动物园管理员按照动物的各种习性加以分类和管理，这样我们才能更加放心安全的观赏动物。

回到企业级应用系统中，随着信息化水平的不断提高，企业级系统变得越来越庞大臃肿，性能急剧下降，客户抱怨频频。拆分系统是目前我们可选择的解决系统可伸缩性和性能问题的唯一行之有效的方法。但是拆分系统同时也带来了系统的复杂性——各子系统不是孤立存在的，它们彼此之间需要协作和交互，这就是我们常说的分布式系统0。各个子系统就好比动物园里的动物，为了使各个子系统能正常为用户提供统一的服务，必须需要一种机制来进行协调——这就是ZooKeeper（动物园管理员）。

Zookeeper的设计目的

我们知道要写一个分布式应用是非常困难的，主要原因就是局部故障。一个消息通过网络在两个节点之间传递时，网络如果发生故障，发送方并不知道接收方是否接收到了这个消息。他可能在网络故障迁就收到了此消息，也坑没有收到，又或者可能接收方的进程死了。发送方了解情况的唯一方法就是再次连接发送方，并向他进行询问。这就是局部故障：根本不知道操作是否失败。因此，大部分分布式应用需要一个主控、协调控制器来管理物理分布的子进程。目前，大部分应用需要开发私有的协调程序，缺乏一个通用的机制。协调程序的反复编写浪费，且难以形成通用、伸缩性好的协调器。协调服务非常容易出错，并很难从故障中恢复。例如：协调服务很容易处于竞态1甚至死锁2。Zookeeper的设计目的，是为了减轻分布式应用程序所承担的协调任务。

Zookeeper并不能阻止局部故障的发生，因为它们的本质是分布式系统。他当然也不会隐藏局部故障。ZooKeeper的目的就是提供一些工具集，用来建立安全处理局部故障的分布式应用。
ZooKeeper是一个分布式小文件系统，并且被设计为高可用性。通过选举算法和集群复制可以避免单点故障3，由于是文件系统，所以即使所有的ZooKeeper节点全部挂掉，数据也不会丢失，重启服务器之后，数据即可恢复。另外ZooKeeper的节点更新是原子的，也就是说更新不是成功就是失败。通过版本号，ZooKeeper实现了更新的乐观锁4，当版本号不相符时，则表示待更新的节点已经被其他客户端提前更新了，而当前的整个更新操作将全部失败。当然所有的一切ZooKeeper已经为开发者提供了保障，我们需要做的只是调用API。与此同时，随着分布式应用的的不断深入，需要对集群管理逐步透明化监控集群和作业状态，可以充分利ZK的独有特性。

Zookeeper简介

    ①Zookeeper是Google的Chubby一个开源的实现，是Hadoop的分布式协调服务
   ②它包含一个简单的原语集，分布式应用程序可以基于它实现同步服务，配置维护和命名维护等
   ③它的文件系统使用了我们所熟悉的目录树结构。
   ④Zookeeper的设计目的是为了减轻分布式应用程序所承担的协调任务

为什么使用Zookeeper

     ①大部分分布式应用需要一个主控、协调器或者控制器来管理物理分布的子进程（如资源，任务分配等）

    ②目前，大部分应用需要开发私有的协调程序，缺乏一个通用的机制

    ③协调程序的反复编写浪费，且难以形成通用、伸缩性号的协调器。

    ④Zookeeper：提供通用的分布式锁服务，用以协调分布式应用

Zookeeper的设计目标

     ①简单化:Zookeeper的数据存放在内存当中，这就意味着Zookeeper可以达到一个高的吞吐量，并且低延迟。

  ②健壮性:组成Zookeeper服务的服务器必须互相知道其他服务器的存在。

  ③有序性:Zookeeper可以为每一次更新操作赋予一个版本号，并且此版本号全局有效，不存在重复

  ④速度优势:它在读取主要负载时尤其快，当读工作比写工作更多的时候，他执行的性能会更好。

Zookeeper集群

ZK集群如下图2.1所示。这是实际应用的一个场景，该ZooKeeper集群当中一共有5台服务器，有两种角色Leader和Follwer，5台服务器连通在一起，客户端有分别连在不同的ZK服务器上。如果当数据通过客户端1，在左边第一台Follower服务器上做了一次数据变更，他会把这个数据的变化同步到其他所有的服务器，同步结束之后，那么其他的客户端都会获得这个数据的变化。

注意：

通常Zookeeper由2n+1台servers组成，每个server都知道彼此的存在。每个server都维护的内存状态镜像以及持久化存储的事务日志和快照。为了保证Leader选举能过得到多数的支持，所以ZooKeeper集群的数量一般为奇数。对于2n+1台server，只要有n+1台（大多数）server可用，整个系统保持可用。

2.3.1 集群中的角色

在ZooKeeper集群当中，集群中的服务器角色有两种Leader和Learner，Learner角色又分为Observer和Follower，具体功能如下：

1.领导者(leader)，负责进行投票的发起和决议，更新系统状态

2.学习者(learner)，包括跟随者（follower）和观察者（observer），

3.follower用于接受客户端请求并向客户端返回结果，在选主过程中参与投票

4.Observer可以接受客户端请求，将写请求转发给leader，但observer不参加投票过程，只同步leader的状态，observer的目的是为了扩展系统，提高读取速度。

5. 客户端(client)，请求发起方

数据模型和层次命名空间

    Zookeeper提供的命名空间与标准的文件系统非常相似。它的名称是由通过斜线分割的路径名称序列组成

    Zookeeper中的每一个节点都是通过路径来识别的。

Zookeeper中的节点

    Zookeeper中的每一个节点还拥有一些自身的信息，包括数据，数据长度，创建时间，修改时间等。

    Znode概念的引用 用来表示所讨论的Zookeeper节点。  具体来说Znode维护着数据、访问控制列表（ACL），

    时间戳等包含交换版本号信息的数据结构

Zookeeper的数据模型

        在Zookeeper中不准使用相对路径

         一，Znode

            Znode是客户端访问Zookeeper的主要实体，每当Znode的数据改变时，他相应的版本号将会增加。         

 stat. 此为状态信息, 描述该znode的版本, 权限等信息.

       data. 与该znode关联的数据.

children. 该znode下的子节点

   它包含以下特征

         （1）Watches

                客户端可以在节点上设置watch(监视器）,当节点的状态发生改变时，将会触发watch相应的操作，只会被触发一次

         （2）数据访问

                Zookeeper中的每个节点上存储的数据需要被原子性操作也就是说读操作将获取与节点相关的所有数据，写操作也将替换掉节点的所有数据。另外，每一个节点都拥有自己的ACL(访问控制列表)，这个列表规定了用户的权限，即限定了特定用户对目标节点可以执行的操作

         （3）临时节点    

                Zookeeper中的节点有两种，分别为临时节点和永久节点。节点的类型在创建是已经被指定，不能被修改。

                ZooKeeper的临时节点：该节点的生命周期依赖于创建它们的会话。一旦会话结束，临时节点将被自动删除，当然可以也可以手动删            除。另外，需要注意是，ZooKeeper的临时节点不允许拥有子节点。
　　    ZooKeeper的永久节点：该节点的生命周期不依赖于会话，并且只有在客户端显示执行删除操作的时候，他们才能被删除。

         （4）顺序节点（唯一性保证）

                当创建Znode的时候，用户可以请求在Zookeeper的路径结尾添加一个递增的计数

                这个计数对于此节点的父节点来说是唯一的，它的格式为“%10d”(10位数字，没有数值的数位用0补充，例如“0000000001”)。当计数值大        于232-1时，计数器将溢出。

        org.apache.zookeeper.CreateMode中定义了四种节点类型，分别对应：

        PERSISTENT：永久节点

        EPHEMERAL：临时节点

        PERSISTENT_SEQUENTIAL：永久节点、序列化

        EPHEMERAL_SEQUENTIAL：临时节点、序列化

        二，Zxid

            致使Zookeeper节点状态改变的每一次操作都将使节点接收到一个zxid格式的时间戳，并且全局有效

            每个Zookeeper都维护者三个zxid值，分别为cZxid,mZxid,pZxid

        三，版本号

            对节点的每一次操作都将致使整个节点的版本号增加。每个节点维护着三个版本号，他们分别是:

                version(节点数据版本号），cversion(子节点版本号），avevsion(节点所拥有的ACL版本号）

        四，节点属性结构

            

 Zookeeper的会话过程

         ZooKeeper客户端与ensemble中的服务器列表配置一致，在启动时，他尝试与表中的一个服务器相连接。如果连接失败了，他就尝试表    中的其他服务器，以此类推，知道他最终连接到其中一个，或者ZooKeeper的所有服务器都无法获得时，连接失败。

    一旦与ZooKeeper服务器连接成功，服务器会创建与客户端的一个新的对话。每个回话都有超时时段，这是应用程序在创建它时设定      的。如果服务器没有在超时时段内得到请求，他可能会中断这个会话。一旦会话被中断了，他可能不再被打开，而且任何与会话相连接     的临时节点都将丢失。

    无论什么时候会话持续空闲长达一定时间，都会由客户端发送ping请求保持活跃（犹如心跳）。时间段要足够小以监测服务器故障（由    读操作超时反应），并且能再回话超市时间段内重新连接到另一个服务器。

    在ZooKeeper中有几个time参数。tick time是ZooKeeper中的基本时间长度，为ensemble里的服务器所使用，用来定义对于交互运行的    调度。其他设置以tick time的名义定义，或者至少由它来约束。

    创建更复杂的临时性状态的应用程序应该支持更长的会话超时，因为重新构建的代价会更昂贵。在一些情况下，我们可以让应用程序在    一定会话时间内能够重启，并且避免会话过期。（这可能更适合执行维护或是升级）每个会话都由服务器给定一个唯一的身份和密码，    而且如果是在建立连接时被传递给ZooKeeper的话，只要没有过期它能够恢复会话。

    这些特性可以视为一种可以避免会话过期的优化，但它并不能代替用来处理会话过期。会话过期可能出现在机器突然故障时，或是由于    任何原因导致的应用程序安全关闭了，但在会话中断前没有重启。

                             

Zookeeper watchs    

读操作exists、getChildren和getData都被设置了watch，并且这些watch都由写操作来触发：create、delete和setData。ACL操作并不参与到watch中。当watch被触发时，watch事件被生成，他的类型由watch和触发他的操作共同决定。ZooKeeper所管理的watch可以分为两类：

1.数据watch（data watches）：getData和exists负责设置数据watch；

2.孩子watch（child watches）：getChildren负责设置孩子watch；

我们可以通过操作返回的数据来设置不同的watch：

1.getData和exists：返回关于节点的数据信息

2.getChildren：返回孩子列表

因此，一个成功的setData操作将触发Znode的数据watch。

一个成功的create操作将触发Znode的数据watch以及孩子watch。

一个成功的delete操作将触发Znode的数据watch以及孩子watch。

watch由客户端所连接的ZooKeeper服务器在本地维护，因此watch可以非常容易地设置、管理和分派。当客户端连接到一个新的服务器上时，任何的会话事件都将可能触发watch。另外，当从服务器断开连接的时候，watch将不会被接收。但是，当一个客户端重新建立连接的时候，任何先前注册过的watch都会被重新注册。

exists操作上的watch，在被监视的Znode创建、删除或数据更新时被触发。

getData操作上的watch，在被监视的Znode删除或数据更新时被触发。在被创建时不能被触发，因为只有Znode一定存在，getData操作才会成功。

getChildren操作上的watch，在被监视的Znode的子节点创建或删除，或是这个Znode自身被删除时被触发。可以通过查看watch事件类型来区分是Znode还是他的子节点被删除：NodeDelete表示Znode被删除，NodeDeletedChanged表示子节点被删除。

watch设置操作及相应的触发器如图下图所示：

watch事件包括了事件所涉及的Znode的路径，因此对于NodeCreated和NodeDeleted事件来说，根据路径就可以简单区分出是哪个Znode被创建或是被删除了。为了查询在NodeChildrenChanged事件后哪个子节点被改变了，需要再次调用getChildren来获得新的children列表。同样的，为了查询NodeDeletedChanged事件后产生的新数据，需要调用getData。在两种情况下，Znode可能在获取watch事件或执行读操作这两种状态下切换，在写应用程序时，必须记住这一点。

（1）Zookeeper的watch实际上要处理两类事件：

1. 连接状态事件(type=None, path=null)

这类事件不需要注册，也不需要我们连续触发，我们只要处理就行了。

2. 节点事件

节点的建立，删除，数据的修改。它是one time trigger，我们需要不停的注册触发，还可能发生事件丢失的情况。

上面2类事件都在Watch中处理，也就是重载的process(Event event)

（2）节点事件的触发，通过函数exists,getData或getChildren来处理

这类函数，有双重作用：

1. 注册触发事件

2. 函数本身的功能

函数的本身的功能又可以用异步的回调函数来实现,重载processResult()过程中处理函数本身的的功能。

函数还可以指定自己的watch,所以每个函数都有4个版本。根据自己的需要来选择不同的函数，不同的版本。

3.3 ZooKeeper访问控制列表ACL

ZooKeeper使用ACL来对Znode进行访问控制。ACL的实现和Unix文件访问许可非常相似：它使用许可位来对一个节点的不同操作进行允许或禁止的权限控制。但是，和标准的Unix许可不同的是，Zookeeper对于用户类别的区分，不止局限于所有者(owner)、组 (group)、所有人(world)三个级别。Zookeeper中，数据节点没有“所有者”的概念。访问者利用id标识自己的身份，并获得与之相应的 不同的访问权限。

注意：

传统的文件系统中，ACL分为两个维度，一个是属组，一个是权限，子目录/文件默认继承父目录的ACL。而在Zookeeper中一个ACL和一个ZooKeeper节点相对应。并且，父节点的ACL与子节点的ACL是相互独立的。也就是说，ACL不能被子节点所继承，父节点所拥有的权限与子节点所用的权限都没有任何关系。

Zookeeper支持可配置的认证机制。它利用一个三元组来定义客户端的访问权限：(scheme:expression, perms) 。其中：

1.scheme：定义了expression的含义。

如：（host:host1.corp.com，READ）,标识了一个名为host1.corp.com的主机,有该数据节点的读权限。

2.Perms：标识了操作权限。

如：（ip:19.22.0.0/16, READ）,表示IP地址以19.22开头的主机,有该数据节点的读权限。

Zookeeper的ACL也可以从三个维度来理解：一是，scheme; 二是，user; 三是，permission，通常表示为scheme:id:permissions，如下图所示。

1.world : id格式：anyone。

如：world:anyone代表任何人，zookeeper中对所有人有权限的结点就是属于world:anyone的。

2.auth : 它不需要id。

注：只要是通过authentication的user都有权限，zookeeper支持通过kerberos来进行认证, 也支持username/password形式的认证。

3.digest: id格式：username:BASE64(SHA1(password))。

它需要先通过username:password形式的authentication。

4.ip: id格式：客户机的IP地址。

设置的时候可以设置一个ip段。如：ip:192.168.1.0/16, 表示匹配前16个bit的IP段

5.super: 超级用户模式。

在这种scheme情况下，对应的id拥有超级权限，可以做任何事情

ZooKeeper权限定义如下图所示：

ZooKeeper内置的ACL模式如下图所示：

当会话建立的时候，客户端将会进行自我验证。另外，ZooKeeper Java API支持三种标准的用户权限，它们分别为：

1.ZOO_PEN_ACL_UNSAFE：对于所有的ACL来说都是完全开放的，任何应用程序可以在节点上执行任何操作，比如创建、列出并删除子节点。

2.ZOO_READ_ACL_UNSAFE：对于任意的应用程序来说，仅仅具有读权限。

3.ZOO_CREATOR_ALL_ACL：授予节点创建者所有权限。需要注意的是，设置此权限之前，创建者必须已经通了服务器的认证。

10,ZooKeeper一致性

在ensemble中的领导者和跟随着非常灵活，跟随者通过更新号来滞后领导者11，结果导致了只要大部分而不是所有的ensemble中的元素确认更新，就能被提交了。对于ZooKeeper来说，一个较好的智能模式是将客户端连接到跟着领导者的ZooKeeper服务器上。客户端可能被连接到领导者上，但他不能控制它，而且在如下情况时，甚至可能不知道。参见下图：

每一个Znode树的更新都会给定一个唯一的全局标识，叫zxid（表示ZooKeeper事务“ID”）。更新是被排序的，因此如果zxid的z1<z2，那么z1就比z2先执行。对于ZooKeeper来说，这是分布式系统中排序的唯一标准。

ZooKeeper是一种高性能、可扩展的服务。ZooKeeper的读写速度非常快，并且读的速度要比写快。另外，在进行读操作的时候，ZooKeeper依然能够为旧的数据提供服务。这些都是由ZooKeeper所提供的一致性保证的，它具有如下特点：

（1）顺序一致性

任何一个客户端的更新都按他们发送的顺序排序，也就意味着如果一个客户端将Znode z的值更新为值a，那么在之后的操作中，他会将z更新为b，在客户端发现z带有值b之后，就不会再看见带有值a的z。

（2）原子性

更新不成功就失败，这意味着如果更新失败了，没有客户端会知道。☆☆

（3）单系统映像

无论客户端连接的是哪台服务器，他与系统看见的视图一样。这就意味着，如果一个客户端在相同的会话时连接了一台新的服务器，他将不会再看见比在之前服务器上看见的更老的系统状态，当服务器系统出故障，同时客户端尝试连接ensemble中的其他机器时，故障服务器的后面那台机器将不会接受连接，直到它连接到故障服务器。

（4）容错性

一旦更新成功后，那么在客户端再次更新他之前，他就固定了，将不再被修改，这就会保证产生下面两种结果：

如果客户端成功的获得了正确的返回代码，那么说明更新已经成功。如果不能够获得返回代码（由于通信错误、超时等原因），那么客户端将不知道更新是否生效。

当故障恢复的时候，任何客户端能够看到的执行成功的更新操作将不会回滚。

（5）实时性

在任何客户端的系统视图上的的时间间隔是有限的，因此他在超过几十秒的时间内部会过期。这就意味着，服务器不会让客户端看一些过时的数据，而是关闭，强制客户端转到一个更新的服务器上。

解释一下：

由于性能原因，读操作由ZooKeeper服务器的内存提供，而且不参与写操作的全局排序。这一特性可能会导致来自使用ZooKeeper外部机制交流的客户端与ZooKeeper状态的不一致。举例来说，客户端A将Znode z的值a更新为a'，A让B来读z，B读到z的值是a而不是a’。这与ZooKeeper的保证机制是相容的（不允许的情况较作“同步一致的交叉客户端视 图”）。为了避免这种情况的发生，B在读取z的值之前，应该先调用z上的sync。Sync操作强制B连接上的ZooKeeper服务器与leader保 持一致这样，当B读到z的值时，他将成为A设置的值（或是之后的值）

容易混淆的是：

sync操作只能被异步调用12。这样操作的原因是你不需要等待他的返回，因为ZooKeeper保证了任何接下去的操作将会发生在sync在服务器上执行以后，即使操作是在sync完成前被调用的。

这些已执行的保证后，ZooKeeper更高级功能的设计与实现将会变得非常容易，例如：leader选举、队列，以及可撤销锁等机制的实现。