zookeeper在分布式系统中的应用

Zookeeper  安装,文件说明

 

Zookeeper 命令行

/启动 ./zkServer.shstart   

/察看状态  ./zkServer.sh status      

验证启动是否成功  ./zkCli.sh -serverlocalhost:2181

ls / 察看目录

get 获取文件内容：

 

 

创建节点

　　使用create命令，可以创建一个Zookeeper节点，如

create [-s] [-e] path data acl

　　其中，-s或-e分别指定节点特性，顺序或临时节点，若不指定，则表示持久节点；acl用来进行权限控制。

创建顺序节点

　　使用 create -s/zk-test 123 命令创建zk-test顺序节点

　　可以看到创建的zk-test节点后面添加了一串数字以示区别。

创建临时节点

　　使用 create -e/zk-temp 123 命令创建zk-temp临时节点

　　临时节点在客户端会话结束后，就会自动删除，下面使用quit命令退出客户端

　　再次使用客户端连接服务端，并使用ls / 命令查看根目录下的节点

　　可以看到根目录下已经不存在zk-temp临时节点了。

创建永久节点

　　使用 create /zk-permanent 123 命令创建zk-permanent永久节点

　　可以看到永久节点不同于顺序节点，不会自动在后面添加一串数字。

 

读取节点

　　与读取相关的命令有ls 命令和get 命令，ls命令可以列出Zookeeper指定节点下的所有子节点，只能查看指定节点下的第一级的所有子节点；get命令可以获取Zookeeper指定节点的数据内容和属性信息。其用法分别如下

lspath [watch]

getpath [watch]

ls2path [watch]

 

 

更新节点

　　使用set命令，可以更新指定节点的数据内容，用法如下

set path data [version]

　　其中，data就是要更新的新内容，version表示数据版本，如将/zk-permanent节点的数据更新为456，可以使用如下命令：set /zk-permanent 456

　　现在dataVersion已经变为1了，表示进行了更新。

删除节点

　　使用delete命令可以删除Zookeeper上的指定节点，用法如下

　　deletepath [version]

　　其中version也是表示数据版本，使用delete /zk-permanent 命令即可删除/zk-permanent节点

　　可以看到，已经成功删除/zk-permanent节点。值得注意的是，若删除节点存在子节点，那么无法删除该节点，必须先删除子节点，再删除父节点。

 

节点属性

ZooKeeper有多种记录时间的形式，其中包含以下几个主要属性：

(1) Zxid

致使ZooKeeper节点状态改变的每一个操作都将使节点接收到一个Zxid格式的时间戳，并且这个时间戳全局有序。也就是说，也就是说，每个对 节点的改变都将产生一个唯一的Zxid(全局唯一)。如果Zxid1的值小于Zxid2的值，那么Zxid1所对应的事件发生在Zxid2所对应的事件之前。实际 上，ZooKeeper的每个节点维护者三个Zxid值，为别为：cZxid、mZxid、pZxid。

① cZxid： 是节点的创建时间所对应的Zxid格式时间戳。
②mZxid：是节点的修改时间所对应的Zxid格式时间戳。

实现中Zxid是一个64为的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch。低32位是个递增计数。 (2) 版本号

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

①     daraVersion：节点数据版本号
②cVersion：子节点版本号
③aclVersion：节点所拥有的ACL版本号

 

 

 

 

 

 

 

 

 

Zookeeper JavaAPI

zookeeper之监听事件总结

 

zookeeper的Watch机制

     一个zk的节点可以被监控，包括这个目录中存储的数据的修改，子节点目录的变化，一旦变化可以通知设置监控的客户端，这个功能是zookeeper对于应用最重要的特性，通过这个特性可以实现的功能包括配置的集中管理，集群管理，分布式锁等等。

      watch机制官方说明：一个Watch事件是一个一次性的触发器，当被设置了Watch的数据发生了改变的时候，则服务器将这个改变发送给设置了Watch的客户端，以便通知它们。

2. zookeeper机制的特点 

   1) 一次性的触发器（one-time trigger）  (存疑)  

      当数据改变的时候，那么一个Watch事件会产生并且被发送到客户端中。但是客户端只会收到一次这样的通知，如果以后这个数据再次发生改变的时候，之前设置Watch的客户端将不会再次收到改变的通知，因为Watch机制规定了它是一个一次性的触发器。          

        当设置监视的数据发生改变时，该监视事件会被发送到客户端，例如，如果客户端调用了getData("/znode1", true) 并且稍后 /znode1 节点上的数据发生了改变或者被删除了，客户端将会获取到 /znode1 发生变化的监视事件，而如果 /znode1 再一次发生了变化，除非客户端再次对 /znode1 设置监视，否则客户端不会收到事件通知。

  2)发送给客户端（Sent to the client）    

      这个表明了Watch的通知事件是从服务器发送给客户端的，是异步的，这就表明不同的客户端收到的Watch的时间可能不同，但是ZooKeeper有保证：当一个客户端在看到Watch事件之前是不会看到结点数据的变化的。例如：A=3，此时在上面设置了一次Watch，如果A突然变成4了，那么客户端会先收到Watch事件的通知，然后才会看到A=4。

      Zookeeper 客户端和服务端是通过 Socket 进行通信的，由于网络存在故障，所以监视事件很有可能不会成功地到达客户端，监视事件是异步发送至监视者的，Zookeeper 本身提供了保序性(ordering guarantee)：即客户端只有首先看到了监视事件后，才会感知到它所设置监视的 znode 发生了变化(a client will never see a change for which it has set awatch until it first sees the watch event). 网络延迟或者其他因素可能导致不同的客户端在不同的时刻感知某一监视事件，但是不同的客户端所看到的一切具有一致的顺序。

   3)被设置Watch的数据（The data forwhich the watch was set）

        这意味着 znode 节点本身具有不同的改变方式。你也可以想象 Zookeeper 维护了两条监视链表：

      数据监视和子节点监视(data watches and child watches) 

      getData() and exists() 设置数据监视，getChildren() 设置子节点监视。或者，你也可以想象 Zookeeper 设置的不同监视返回不同的数据，getData() 和 exists() 返回 znode 节点的相关信息，而 getChildren() 返回子节点列表。

      因此， setData() 会触发设置在某一节点上所设置的数据监视(假定数据设置成功)，而一次成功的 create() 操作则会出发当前节点上所设置的数据监视以及父节点的子节点监视。一次成功的 delete() 操作将会触发当前节点的数据监视和子节点监视事件，同时也会触发该节点父节点的child watch。

3.各种watch触发的情况总结

      可以注册watcher的方法：getData、exists、getChildren。

      可以触发watcher的方法：create、delete、setData。连接断开的情况下触发的watcher会丢失。

      一个Watcher实例是一个回调函数，被回调一次后就被移除了。如果还需要关注数据的变化，需要再次注册watcher。

        New ZooKeeper时注册的watcher叫default watcher，它不是一次性的，只对client的连接状态变化作出反应。

     什么样的操作会产生什么类型的事件:

	event For “/path”	event For “/path/child”
create(“/path”)	EventType.NodeCreated	无
delete(“/path”)	EventType.NodeDeleted	无
setData(“/path”)	EventType.NodeDataChanged	无
create(“/path/child”)	EventType.NodeChildrenChanged（getChild）	EventType.NodeCreated
delete(“/path/child”)	EventType.NodeChildrenChanged（getChild）	EventType.NodeDeleted
setData(“/path/child”)	无	EventType.NodeDataChanged

     事件类型与watcher的对应关系：

event For “/path”	Default Watcher	exists(“/path”)	getData(“/path”)	getChildren(“/path”)
EventType.None	√	√	√	√
EventType.NodeCreated		√	√
EventType.NodeDeleted		√	√
EventType.NodeDataChanged		√	√
EventType.NodeChildrenChanged				√

   本表总结：exits和getData设置数据监视，而getChildren设置子节点监视

     操作与watcher的对应关系：  

	exits("/path")	getData(“/path”)	getChildren(“/path”)	exits("/path/child")	getData(“/path/child”)	getChildren(“/path/child”)
create(“/path”)	√	√	会报错
delete(“/path”)	√	√	√（这个要注意）
setData(“/path”)	√	√
create(“/path/child”)			√	√	√
delete(“/path/child”)			√	√	√	√
setData(“/path/child”)				√	√

值得注意的是：getChildren("/path")监视/path的子节点，如果（/path）自己删了，也会触发NodeDeleted事件。

 

Watch机制

Zookeeper客户端在数据节点上设置监视，则当数据节点发生变化时，客户端会收到提醒。ZooKeeper中的各种读请求，如getDate()，getChildren()，和exists()，都可以选择加"监视点"(watch)。"监视点"指的是一种一次性的触发器(trigger)，当受监视的数据发生变化时，该触发器会通知客户端。

(1) 监视机制有三个关键点：

① "监视点"是一次性的，当触发过一次之后，除非重新设置，新的数据变化不会提醒客户端。

② "监视点"将数据改变的通知客户端。如果数据改变是客户端A引起的，不能保证"监视点"通知事件会在引发数据修改的函数返回前到达客户端A。

③ 对于"监视点"，ZooKeeper有如下保证：客户端一定是在接收到"监视"事件（watch event）之后才接收到数据的改变信息。

(2) "监视点"保留在ZooKeeper服务器上，则当客户端连接到新的ZooKeeper服务器上时，所有需要被触发的相关"监视点"都会被触发。当客户端断线后重连，与它的相关的"监视点"都会自动重新注册，这对客户端来说是透明的。在以下情况，"监视点"会被错过：客户端B设置了关于节点A存在性的"监视点"，但B断线了，在B断线过程中节点A被创建又被删除。此时，B再连线后不知道A节点曾经被创建过。

(3) ZooKeeper的"监视"机制保证以下几点：

① "监视"事件的触发顺序和事件的分发顺序一致。

② 客户端将先接收到"监视"事件，然后才收到新的数据

③ "监视"事件触发的顺序与ZooKeeper服务器上数据变化的顺序一致

(4) 关于ZooKeeper"监视"机制的注意点：

① "监视点"是一次性的。

② 由于"监视点"是一次性的，而且，从接收到"监视"事件到设置新"监视点"是有延时的，所以客户端可能监控不到数据的所有变化。

③ 一个监控对象，只会被相关的通知触发一次。如果一个客户端设置了关于某个数据点exists和getData的监控，则当该数据被删除的时候，只会触发"文件被删除"的

通知。

④ 当客户端断开与服务器的连接时，客户端不再能收到"监视"事件，直到重新获得连接。所以关于Session的信息将被发送给所有ZooKeeper服务器。由于当连接断开时收不到"监视"，所以在这种情况下，模块行为需要容错方面的设计。

 

ZooKeeper的读写机制

概述

ZooKeeper的核心思想是，提供一个非锁机制的WaitFree的用于分布式系统同步的核心服务。提供简单的文件创建、读写操作接口，其系统核心本身对文件读写并不提供加锁互斥的服务，但是提供基于版本比对的更新操作，客户端可以基于此自己实现加锁逻辑。如下图1.3所示。

图 1.3 Using versions to prevent inconsistencies due to concurrentupdates

 

 

ZK集群服务

 Zookeeper是一个由多个Server组成的集群，该集群有一个Leader，多个Follower。客户端可以连接任意ZooKeeper服务节点来读写数据，如下图1.4所示。

图 1.4 ZooKeeper集群服务

 

 

ZK集群中每个Server，都保存一份数据副本。Zookeeper使用简单的同步策略，通过以下两条基本保证来实现数据的一致性：

① 全局串行化所有的写操作

② 保证同一客户端的指令被FIFO执行（以及消息通知的FIFO）

所有的读请求由Zk Server 本地响应，所有的更新请求将转发给Leader，由Leader实施。

 

两阶段提交

 

 

 

 

 

一致性原理:

Zookeeper提供的一致性是弱一致性,首先数据的复制有如下规则:zookeeper确保对znode树的每一个修改都会被复制到集合体中超过半数的机器上。那么就有可能有节点的数据不是最新的而被客户端访问到。并且会有一个时间点,在集群中是不一致的.

也就是Zookeeper只保证最终一致性, 但是实时的一致性可以由客户端调用自己来保证,通过调用sync()方法.

 

用分布式系统的CAP原则来分析Zookeeper.

1)C: Zookeeper保证了最终一致性,在十几秒可以Sync到各个节点.

2)A: Zookeeper保证了可用性,数据总是可用的,没有锁.并且有一大半的节点所拥有的数据是最新的,实时的. 如果想保证取得是数据一定是最新的,需要手工调用Sync()

3)P: 有2点需要分析的.

          节点多了会导致写数据延时非常大,因为需要多个节点同步.

          节点多了Leader选举非常耗时, 就会放大网络的问题. 可以通过引入observer节点缓解这个问题.

 

 

 

 

http://www.cnblogs.com/wuxl360/p/5817646.html

一、ZooKeeper 的实现

1.1ZooKeeper处理单点故障

我们知道可以通过ZooKeeper对分布式系统进行Master选举，来解决分布式系统的单点故障，如图所示。

图 1.1 ZooKeeper解决单点故障

 

那么我们继续分析一下，ZooKeeper通过Master选举来帮助分布式系统解决单点故障，保证该系统中每时每刻只有一个Master为分布式系统提供服务。也就是说分布式的单点问题交给了ZooKeeper来处理，不知道大家此时有没有发现一 个问题——"故障转移到了ZooKeeper身上"。大家看一下图就会发现，如果我们的ZooKeeper只用一台机器来提供服务，若这台机器挂了，那么 该分布式系统就直接变成双Master模式了，那么我们在分布式系统中引入ZooKeeper也就失去了意义。那么这也就意味着，ZooKeeper在其实现的过程中要做一些可用性和恢复性的保证。这样才能让我们放心的以ZooKeeper为起点来构建我们的分布式系统，来达到节省成本和减少bug的目的。

1.2ZooKeeper运行模式

ZooKeeper服务有两种不同的运行模式。一种是"独立模式"(standalonemode)，即只有一个ZooKeeper服务器。这种模式较为简单，比较适合于测试环境，甚至可以在单元测试中采用，但是不能保证高可用性和恢复性。在生产环境中的ZooKeeper通常以"复制模式"(replicated mode)运行于一个计算机集群上，这个计算机集群被称为一个"集合体"(ensemble)。

图 1.2 ZooKeeper集群

ZooKeeper通过复制来实现高可用性，只要集合体中半数以上的机器处于可用状态，它就能够提供服务。例如，在一个有5个节点的集合体中，每个Follower节点的数据都是Leader节点数据的副本，也就是说我们的每个节点的数据视图都是一样的，这样就可以有五个节点提供ZooKeeper服务。并且集合体中任意2台机器出现故障，都可以保证服务继续，因为剩下的3台机器超过了半数。

注意，6个节点的集合体也只能够容忍2台机器出现故障，因为如果3台机器出现故障，剩下的3台机器没有超过集合体的半数。出于这个原因，一个集合体通常包含奇数台机器。

从概念上来说，ZooKeeper它所做的就是确保对Znode树的每一个修改都会被复制到集合体中超过半数的 机器上。如果少于半数的机器出现故障，则最少有一台机器会保存最新的状态，那么这台机器就是我们的Leader。其余的副本最终也会更新到这个状态。如果 Leader挂了，由于其他机器保存了Leader的副本，那就可以从中选出一台机器作为新的Leader继续提供服务。

1.3ZooKeeper的读写机制

(1) 概述

ZooKeeper的核心思想是，提供一个非锁机制的WaitFree的用于分布式系统同步的核心服务。提供简单的文件创建、读写操作接口，其系统核心本身对文件读写并不提供加锁互斥的服务，但是提供基于版本比对的更新操作，客户端可以基于此自己实现加锁逻辑。如下图1.3所示。

图 1.3 Using versions to prevent inconsistencies due to concurrentupdates

 

 

(2) ZK集群服务

 Zookeeper是一个由多个Server组成的集群，该集群有一个Leader，多个Follower。客户端可以连接任意ZooKeeper服务节点来读写数据，如下图1.4所示。

图 1.4 ZooKeeper集群服务

 

ZK集群中每个Server，都保存一份数据副本。Zookeeper使用简单的同步策略，通过以下两条基本保证来实现数据的一致性：

① 全局串行化所有的写操作

② 保证同一客户端的指令被FIFO执行（以及消息通知的FIFO）

所有的读请求由Zk Server 本地响应，所有的更新请求将转发给Leader，由Leader实施。

(3) ZK组件

ZK组件，如图1.5所示。ZK组件除了请求处理器（Request Processor）以外，组成ZK服务的每一个Server会复制这些组件的副本。 

图 ZooKeeper组件图

 

 

ReplicatedDatabase是一个内存数据库，它包含了整个DataTree。为了恢复，更新会被记录到磁盘，并且写在被应用到内存数据库之前，先被序列化到磁盘。

每一个ZK Server，可服务于多个Client。Client可以连接到一台Server，来提交请求。读请求，由每台Server数据库的本地副本来进行服务。改变服务器的状态的写请求，需要通过一致性协议来处理。

作为一致性协议的一部分，来自Client的所有写请求，都要被转发到一个单独的Server，称作Leader。ZK集群中其他Server称作Follower，负责接收Leader发来的提议消息，并且对消息转发达成一致。消息层处理leader失效，同步Followers和Leader。

ZooKeeper使用自定义的原子性消息协议。由于消息传送层是原子性的，ZooKeeper能够保证本地副本不产生分歧。当leader收到一个写请求，它会计算出当写操作完成后系统将会是什么状态，接着将之转变为一个捕获状态的事务。

(4) ZK性能

ZooKeeper被应用程序广泛使用，并有数以千计的客户端同时的访问它，所以我们需要高吞吐量。我们为ZooKeeper 设计的工作负载的读写比例是 2：1以上。然而我们发现，ZooKeeper的高写入吞吐量，也允许它被用于一些写占主导的工作负载。ZooKeeper通过每台Server上的本地 ZK的状态副本，来提供高读取吞吐量。因此，容错性和读吞吐量是以添加到该服务的服务器数量为尺度。写吞吐量并不以添加到该服务的机器数量为尺度。

例如，在它的诞生地Yahoo公司，对于写占主导的工作负载来说，ZooKeeper的基准吞吐量已经超过每秒10000个操作；对于常规的以读为主导的工作负载来说，吞吐量更是高出了好几倍。

二、ZooKeeper的保证

经过上面的分析，我们知道要保证ZooKeeper服务的高可用性就需要采用分布式模式，来冗余数据写多份，写多份带来一致性问题，一致性问题又会带来性能问题，那么就此陷入了无解的死循环。那么在这，就涉及到了我们分布式领域的著名的CAP理论，在这就简单的给大家介绍一下，关于CAP的详细内容大家可以网上查阅。

2.1 CAP理论

(1) 理论概述

分布式领域中存在CAP理论：

① C：Consistency，一致性，数据一致更新，所有数据变动都是同步的。

② A：Availability，可用性，系统具有好的响应性能。

③ P：Partition tolerance，分区容错性。以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择，也就是说无论任何消息丢失，系统都可用。

该理论已被证明：任何分布式系统只可同时满足两点，无法三者兼顾。因此，将精力浪费在思考如何设计能满足三者的完美系统上是愚钝的，应该根据应用场景进行适当取舍。

(2) 一致性分类

一致性是指从系统外部读取系统内部的数据时，在一定约束条件下相同，即数据变动在系统内部各节点应该是同步的。根据一致性的强弱程度不同，可以将一致性级别分为如下几种：

① 强一致性（strong consistency）。任何时刻，任何用户都能读取到最近一次成功更新的数据。

② 单调一致性（monotonicconsistency）。任何时刻，任何用户一旦读到某个数据在某次更新后的值，那么就不会再读到比这个值更旧的值。也就是说，可获取的数据顺序必是单调递增的。

③ 会话一致性（sessionconsistency）。任何用户在某次会话中，一旦读到某个数据在某次更新后的值，那么在本次会话中就不会再读到比这个值更旧的值。会话一致性是在单调一致性的基础上进一步放松约束，只保证单个用户单个会话内的单调性，在不同用户或同一用户不同会话间则没有保障。

④ 最终一致性（eventual consistency）。用户只能读到某次更新后的值，但系统保证数据将最终达到完全一致的状态，只是所需时间不能保障。

⑤ 弱一致性（weak consistency）。用户无法在确定时间内读到最新更新的值。

2.2ZooKeeper与CAP理论

我们知道ZooKeeper也是一种分布式系统，它在一致性上有人认为它提供的是一种强一致性的服务（通过sync操作），也有人认为是单调一致性（更新时的大多说概念），还有人为是最终一致性（顺序一致性），反正各有各的道理这里就不在争辩了。然后它在分区容错性和可用性上做了一定折中，这和CAP理论是吻合的。ZooKeeper从以下几点保证了数据的一致性

① 顺序一致性

来自任意特定客户端的更新都会按其发送顺序被提交。也就是说，如果一个客户端将Znode z的值更新为a，在之后的操作中，它又将z的值更新为b，则没有客户端能够在看到z的值是b之后再看到值a（如果没有其他对z的更新）。

② 原子性

每个更新要么成功，要么失败。这意味着如果一个更新失败，则不会有客户端会看到这个更新的结果。

③ 单一系统映像

一 个客户端无论连接到哪一台服务器，它看到的都是同样的系统视图。这意味着，如果一个客户端在同一个会话中连接到一台新的服务器，它所看到的系统状态不会比在之前服务器上所看到的更老。当一台服务器出现故障，导致它的一个客户端需要尝试连接集合体中其他的服务器时，所有滞后于故障服务器的服务器都不会接受该 连接请求，除非这些服务器赶上故障服务器。

④ 持久性

一个更新一旦成功，其结果就会持久存在并且不会被撤销。这表明更新不会受到服务器故障的影响。

三、ZooKeeper原理

3.1 原理概述

Zookeeper的核心是原子广播机制，这个机制保证了各个server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式和广播模式。

(1) 恢复模式

当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数server完成了和leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和server具有相同的系统状态。

(2) 广播模式

一旦Leader已经和多数的Follower进行了状态同步后，他就可以开始广播消息了，即进入广播状态。这时候当一个Server加入ZooKeeper服务中，它会在恢复模式下启动，发现Leader，并和Leader进行状态同步。待到同步结束，它也参与消息广播。ZooKeeper服务一直维持在Broadcast状态，直到Leader崩溃了或者Leader失去了大部分的Followers支持。

Broadcast模式极其类似于分布式事务中的2pc（two-phrase commit 两阶段提交）：即Leader提起一个决议，由Followers进行投票，Leader对投票结果进行计算决定是否通过该决议，如果通过执行该决议（事务），否则什么也不做。

图3.1两阶段提交

在广播模式ZooKeeper Server会接受Client请求，所有的写请求都被转发给领导者，再由领导者将更新广播给跟随者。当半数以上的跟随者已经将修改持久化之后，领导者才会提交这个更新，然后客户端才会收到一个更新成功的响应。这个用来达成共识的协议被设计成具有原子性，因此每个修改要么成功要么失败。

图 3.2 ZooKeeper数据流动图

 

3.2 Zab协议详解

3.2.1 广播模式

广播模式类似一个简单的两阶段提交：Leader发起一个请求，收集选票，并且最终提交，图3.3演示了我们协议的消息流程。我们可以简化该两阶段提交协议，因为我们并没有"aborts"的情况。followers要么确认Leader的Propose，要么丢弃该Leader的Propose。没有"aborts"意味着，只要有指定数量的机器确认了该Propose，而不是等待所有机器的回应。

图 3.3 The flow of message with protocol

广播协议在所有的通讯过程中使用TCP的FIFO信道，通过使用该信道，使保持有序性变得非常的容易。通过FIFO信道，消息被有序的deliver。只要收到的消息一被处理，其顺序就会被保存下来。

Leader会广播已经被deliver的Proposal消息。在发出一个Proposal消息前，Leader会分配给Proposal一个单调递增的唯一id，称之为zxid。因为Zab保证了因果有序， 所以递交的消息也会按照zxid进行排序。广播是把Proposal封装到消息当中，并添加到指向Follower的输出队列中，通过FIFO信道发送到 Follower。当Follower收到一个Proposal时，会将其写入到磁盘，可以的话进行批量写入。一旦被写入到磁盘媒介当 中，Follower就会发送一个ACK给Leader。 当Leader收到了指定数量的ACK时，Leader将广播commit消息并在本地deliver该消息。当收到Leader发来commit消息 时，Follower也会递交该消息。

需要注意的是， 该简化的两阶段提交自身并不能解决Leader故障，所以我们 添加恢复模式来解决Leader故障。

3.2.2 恢复模式

(1) 恢复阶段概述

正常工作时Zab协议会一直处于广播模式，直到Leader故障或失去了指定数量的Followers。 为了保证进度，恢复过程中必须选举出一个新Leader，并且最终让所有的Server拥有一个正确的状态。对于Leader选举，需要一个能够成功高几率的保证存活的算法。Leader选举协议，不仅能够让一个Leader得知它是leader，并且有指定数量的Follower同意该决定。如果 Leader选举阶段发生错误，那么Servers将不会取得进展。最终会发生超时，重新进行Leader选举。在我们的实现中，Leader选举有两种不同的实现方式。如果有指定数量的Server正常运行，快速选举的完成只需要几百毫秒。

(2)恢复阶段的保证

该恢复过程的复杂部分是在一个给定的时间内，提议冲突的绝对数量。最大数量冲突提议是一个可配置的选项，但是默认是1000。为了使该协议能够即使在Leader故障的情况下也能正常运作。我们需要做出两条具体的保证：

① 我们绝不能遗忘已经被deliver的消息，若一条消息在一台机器上被deliver，那么该消息必须将在每台机器上deliver。

② 我们必须丢弃已经被skip的消息。

(3) 保证示例

第一条：

若一条消息在一台机器上被deliver，那么该消息必须将在每台机器上deliver，即使那台机器故障了。例如，出现了这样一种情况：Leader发送了commit消息，但在该commit消息到达其他任何机器之前，Leader发生了故障。也就是说，只有Leader自己收到了commit消息。如图3.4中的C2。

图 3.4 The flow of message with protocol

图3.4是"第一条保证"（deliver消息不能忘记）的一个示例。在该图中Server1是一个Leader，我们用L1表示，Server2和Server3为Follower。首先Leader发起了两个Proposal，P1和P2，并将P1、P2发送给了Server1和Server2。然后Leader对P1发起了Commit即C1，之后又发起了一个Proposal即P3，再后来又对P2发起了commit即C2，就在此时我们的Leader挂了。那么这时候，P3和C2这两个消息只有Leader自己收到了。

因为Leader已经deliver了该C2消息，client能够在消息中看到该事务的结果。所以该事务必须能够在其他所有的Server中deliver，最终使得client看到了一个一致性的服务视图。

第二条：

一个被skip的消息，必须仍然需要被skip。例如，发生了这样一种情况：Leader发送了propose消息，但在该propose消息到达其他任何机器之前，Leader发生了故障。也就是说，只有Leader自己收到了propose消息。如图3.4中的P3所示。

在图3.4中没有任何一个server能够看到3号提议，所以在图3.5中当server 1恢复时他需要在系统恢复时丢弃三号提议P3。

图3.5

在图3.5是"第二条保证"（skip消息必须被丢弃）的一个示例。Server1挂掉以后，Server3被选举为Leader，我们用L2表示。L2中还有未被deliver的消息P1、P2，所以，L2在发出新提议P10000001、P10000002之前，L2先将P1、P2两个消息deliver。因此，L2先发出了两个commit消息C1、C2，之后L2才发出了新的提议P10000001和P10000002。

如果Server1 恢复之后再次成为了Leader，此时再次将P3在P10000001和P10000002之后deliver，那么将违背顺序性的保障。

(4) 保证的实现

如果Leader选举协议保证了新Leader在QuorumServer中具有最高的提议编号，即Zxid最高。那么新选举出来的leader将具有所有已deliver的消息。新选举出来的Leader，在提出一个新消息之前，首先要保证事务日志中的所有消息都由Quorum Follower已Propose并deliver。需要注意的是，我们可以让新Leader成为一个用最高zxid来处理事务的server，来作为一个优化。这样，作为新被选举出来的Leader，就不必去从一组Followers中找出包含最高zxid的Followers和获取丢失的事务。

① 第一条

所有的正确启动的Servers，将会成为Leader或者跟随一个Leader。Leader能够确保它的Followers看到所有的提议，并deliver所有已经deliver的消息。通过将新连接上的Follower所没有见过的所有PROPOSAL进行排队，并之后对该Proposals的COMMIT消息进行排队，直到最后一个COMMIT消息。在所有这样的消息已经排好队之后，Leader将会把Follower加入到广播列表，以便今后的提议和确认。这一条是为了保证一致性，因为如果一条消息P已经在旧Leader-Server1中deliver了，即使它刚刚将消息P deliver之后就挂了，但是当旧Leader-Server1重启恢复之后，我们的Client就可以从该Server中看到该消息P deliver的事务，所以为了保证每一个client都能看到一个一致性的视图，我们需要将该消息在每个Server上deliver。

② 第二条

skip已经Propose，但不能deliver的消息，处理起来也比较简单。在我们的实现中，Zxid是由64位数字组成的，低32位用作简单计数器。高32位是一个epoch。每当新Leader接管它时，将获取日志中Zxid最大的epoch，新Leader Zxid的epoch位设置为epoch+1，counter位设置0。用epoch来标记领导关系的改变,并要求QuorumServers 通过epoch来识别该leader，避免了多个Leader用同一个Zxid发布不同的提议。

这 个方案的一个优点就是，我们可以skip一个失败的领导者的实例，从而加速并简化了恢复过程。如果一台宕机的Server重启，并带有未发布的 Proposal，那么先前的未发布的所有提议将永不会被deliver。并且它不能够成为一个新leader，因为任何一种可能的 Quorum Servers ，都会有一个Server其Proposal 来自与一个新epoch因此它具有一个较高的zxid。当Server以Follower的身份连接，领导者检查自身最后提交的提议，该提议的epoch 为Follower的最新提议的epoch（也就是图3.5中新Leader-Server2中deliver的C2提议），并告诉Follower截断事务日志直到该epoch在新Leader中deliver的最后的Proposal即C2。在图3.5中，当旧Leader-Server1连接到了新leader-Server2，leader将告诉他从事务日志中清除3号提议P3，具体点就是清除P2之后的所有提议，因为P2之后的所有提议只有旧Leader-Server1知道，其他Server不知道。

(5) Paxos与Zab

① Paxos一致性

Paxos的一致性不能达到ZooKeeper的要 求，我们可以下面一个例子。我们假设ZK集群由三台机器组成，Server1、Server2、Server3。Server1为Leader，他生成了 三条Proposal，P1、P2、P3。但是在发送完P1之后，Server1就挂了。如下图3.6所示。

图 3.6 Server1为Leader

Server1挂掉之后，Server3被选举成为Leader，因为在Server3里只有一条Proposal—P1。所以，Server3在P1的基础之上又发出了一条新Proposal—P2＇，P2＇的Zxid为02。如下图3.7所示。

图3.7 Server2成为Leader

Server2发送完P2＇之后，它也挂了。此时Server1已经重启恢复，并再次成为了Leader。那么，Server1将发送还没有被deliver的Proposal—P2和P3。由于Follower-Server2中P2＇的Zxid为02和Leader-Server1中P2的Zxid相等，所以P2会被拒绝。而P3，将会被Server2接受。如图3.8所示。

图3.8 Server1再次成为Leader

我们分析一下Follower-Server2中的Proposal，由于P2'将P2的内容覆盖了。所以导致，Server2中的Proposal-P3无法生效，因为他的父节点并不存在。

② Zab一致性

首先来分析一下，上面的示例中为什么不满足ZooKeeper需求。ZooKeeper是一个树形结构，很多操作都要先检查才能确定能不能执行，比如，在图3.8中Server2有三条Proposal。P1的事务是创建节点"/zk"，P2'是创建节点"/c"，而P3是创建节点 "/a/b",由于"/a"还没建，创建"a/b"就搞不定了。那么，我们就能从此看出Paxos的一致性达不到ZooKeeper一致性的要求。

为了达到ZooKeeper所需要的一致性，ZooKeeper采用了Zab协议。Zab做了如下几条保证，来达到ZooKeeper要求的一致性。

(a) Zab要保证同一个leader的发起的事务要按顺序被apply，同时还要保证只有先前的leader的所有事务都被apply之后，新选的leader才能在发起事务。

(b) 一些已经Skip的消息，需要仍然被Skip。

我想对于第一条保证大家都能理解，它主要是为了保证每个Server的数据视图的一致性。我重点解释一下第二条，它是如何实现。为了能够实现，Skip已经被skip的消息。我们在Zxid中引入了 epoch，如下图所示。每当Leader发生变换时，epoch位就加1，counter位置0。

图 3.9 Zxid

我们继续使用上面的例子，看一下他是如何实现Zab的 第二条保证的。我们假设ZK集群由三台机器组成，Server1、Server2、Server3。Server1为Leader，他生成了三条 Proposal，P1、P2、P3。但是在发送完P1之后，Server1就挂了。如下图3.10所示。

图 3.10 Server1为Leader

Server1挂掉之后，Server3被选举成为 Leader，因为在Server3里只有一条Proposal—P1。所以，Server3在P1的基础之上又发出了一条新Proposal—P2＇， 由于Leader发生了变换，epoch要加1，所以epoch由原来的0变成了1，而counter要置0。那么，P2＇的Zxid为10。如下图3.11所示。

图 3.11 Server3为Leader

Server2发送完P2＇之后，它也挂了。此时Server1已经重启恢复，并再次成为了Leader。那么，Server1将发送还没有被deliver的Proposal—P2和P3。由于Server2中P2＇的Zxid为10，而Leader-Server1中P2和P3的Zxid分别为02和03，P2＇的epoch位高于P2和P3。所以此时Leader-Server1的P2和P3都会被拒绝,那么我们Zab的第二条保证也就实现了。如图3.12所示。

图 3.12 Server1再次成为Leader

 

 

Zookeeper 应用:

 

分布式锁

　　分布式锁用于控制分布式系统之间同步访问共享资源的一种方式，可以保证不同系统访问一个或一组资源时的一致性，主要分为排它锁和共享锁。

排它锁又称为写锁或独占锁，若事务T1对数据对象O1加上了排它锁，那么在整个加锁期间，只允许事务T1对O1进行读取和更新操作，其他任何事务都不能再对这个数据对象进行任何类型的操作，直到T1释放了排它锁。

① 获取锁，在需要获取排它锁时，所有客户端通过调用接口，在/exclusive_lock节点下创建临时子节点/exclusive_lock/lock。Zookeeper可以保证只有一个客户端能够创建成功，没有成功的客户端需要注册/exclusive_lock节点监听。

② 释放锁，当获取锁的客户端宕机或者正常完成业务逻辑都会导致临时节点的删除，此时，所有在/exclusive_lock节点上注册监听的客户端都会收到通知，可以重新发起分布式锁获取。

共享锁又称为读锁，若事务T1对数据对象O1加上共享锁，那么当前事务只能对O1进行读取操作，其他事务也只能对这个数据对象加共享锁，直到该数据对象上的所有共享锁都被释放。

① 获取锁，在需要获取共享锁时，所有客户端都会到/shared_lock下面创建一个临时顺序节点，如果是读请求，那么就创建例如/shared_lock/host1-R-00000001的节点，如果是写请求，那么就创建例如/shared_lock/host2-W-00000002的节点。

② 判断读写顺序，不同事务可以同时对一个数据对象进行读写操作，而更新操作必须在当前没有任何事务进行读写情况下进行，通过Zookeeper来确定分布式读写顺序，大致分为四步。

1. 创建完节点后，获取/shared_lock节点下所有子节点，并对该节点变更注册监听。

2. 确定自己的节点序号在所有子节点中的顺序。

3. 对于读请求：若没有比自己序号小的子节点或所有比自己序号小的子节点都是读请求，那么表明自己已经成功获取到共享锁，同时开始执行读取逻辑，若有写请求，则需要等待。对于写请求：若自己不是序号最小的子节点，那么需要等待。

4. 接收到Watcher通知后，重复步骤1。

③ 释放锁，其释放锁的流程与独占锁一致。

　　上述共享锁的实现方案，可以满足一般分布式集群竞争锁的需求，但是如果机器规模扩大会出现一些问题，下面着重分析判断读写顺序的步骤3。

　　针对如上图所示的情况进行分析

1. host1首先进行读操作，完成后将节点/shared_lock/host1-R-00000001删除。

2. 余下4台机器均收到这个节点移除的通知，然后重新从/shared_lock节点上获取一份新的子节点列表。

3. 每台机器判断自己的读写顺序，其中host2检测到自己序号最小，于是进行写操作，余下的机器则继续等待。

4. 继续...

　　可以看到，host1客户端在移除自己的共享锁后，Zookeeper发送了子节点更变Watcher通知给所有机器，然而除了给host2产生影响外，对其他机器没有任何作用。大量的Watcher通知和子节点列表获取两个操作会重复运行，这样会造成系能鞥影响和网络开销，更为严重的是，如果同一时间有多个节点对应的客户端完成事务或事务中断引起节点小时，Zookeeper服务器就会在短时间内向其他所有客户端发送大量的事件通知，这就是所谓的羊群效应。

　　可以有如下改动来避免羊群效应。

1. 客户端调用create接口常见类似于/shared_lock/[Hostname]-请求类型-序号的临时顺序节点。

2. 客户端调用getChildren接口获取所有已经创建的子节点列表（不注册任何Watcher）。

3. 如果无法获取共享锁，就调用exist接口来对比自己小的节点注册Watcher。对于读请求：向比自己序号小的最后一个写请求节点注册Watcher监听。对于写请求：向比自己序号小的最后一个节点注册Watcher监听。

4. 等待Watcher通知，继续进入步骤2。

　　此方案改动主要在于：每个锁竞争者，只需要关注/shared_lock节点下序号比自己小的那个节点是否存在即可。

 

 

代码

 

 

 

 

Master选举

　　在分布式系统中，Master往往用来协调集群中其他系统单元，具有对分布式系统状态变更的决定权，如在读写分离的应用场景中，客户端的写请求往往是由Master来处理，或者其常常处理一些复杂的逻辑并将处理结果同步给其他系统单元。利用Zookeeper的强一致性，能够很好地保证在分布式高并发情况下节点的创建一定能够保证全局唯一性，即Zookeeper将会保证客户端无法重复创建一个已经存在的数据节点。

　　首先创建/master_election/2016-11-12节点，客户端集群每天会定时往该节点下创建临时节点，如/master_election/2016-11-12/binding，这个过程中，只有一个客户端能够成功创建，此时其变成master，其他节点都会在节点/master_election/2016-11-12上注册一个子节点变更的Watcher，用于监控当前的Master机器是否存活，一旦发现当前Master挂了，其余客户端将会重新进行Master选举。

代码

 

 

数据发布/订阅

　　数据发布/订阅系统，即配置中心。需要发布者将数据发布到Zookeeper的节点上，供订阅者进行数据订阅，进而达到动态获取数据的目的，实现配置信息的集中式管理和数据的动态更新。发布/订阅一般有两种设计模式：推模式和拉模式，服务端主动将数据更新发送给所有订阅的客户端称为推模式；客户端主动请求获取最新数据称为拉模式，Zookeeper采用了推拉相结合的模式，客户端向服务端注册自己需要关注的节点，一旦该节点数据发生变更，那么服务端就会向相应的客户端推送Watcher事件通知，客户端接收到此通知后，主动到服务端获取最新的数据。

　　若将配置信息存放到Zookeeper上进行集中管理，在通常情况下，应用在启动时会主动到Zookeeper服务端上进行一次配置信息的获取，同时，在指定节点上注册一个Watcher监听，这样在配置信息发生变更，服务端都会实时通知所有订阅的客户端，从而达到实时获取最新配置的目的。

 

负载均衡

　　负载均衡是一种相当常见的计算机网络技术，用来对多个计算机、网络连接、CPU、磁盘驱动或其他资源进行分配负载，以达到优化资源使用、最大化吞吐率、最小化响应时间和避免过载的目的。

　　使用Zookeeper实现动态DNS服务

· 域名配置，首先在Zookeeper上创建一个节点来进行域名配置，如DDNS/app1/server.app1.company1.com。

· 域名解析，应用首先从域名节点中获取IP地址和端口的配置，进行自行解析。同时，应用程序还会在域名节点上注册一个数据变更Watcher监听，以便及时收到域名变更的通知。

· 域名变更，若发生IP或端口号变更，此时需要进行域名变更操作，此时，只需要对指定的域名节点进行更新操作，Zookeeper就会向订阅的客户端发送这个事件通知，客户端之后就再次进行域名配置的获取。

 

 

命名服务

　　命名服务是分步实现系统中较为常见的一类场景，分布式系统中，被命名的实体通常可以是集群中的机器、提供的服务地址或远程对象等，通过命名服务，客户端可以根据指定名字来获取资源的实体、服务地址和提供者的信息。Zookeeper也可帮助应用系统通过资源引用的方式来实现对资源的定位和使用，广义上的命名服务的资源定位都不是真正意义上的实体资源，在分布式环境中，上层应用仅仅需要一个全局唯一的名字。Zookeeper可以实现一套分布式全局唯一ID的分配机制。

　　通过调用Zookeeper节点创建的API接口就可以创建一个顺序节点，并且在API返回值中会返回这个节点的完整名字，利用此特性，可以生成全局ID，其步骤如下

1. 客户端根据任务类型，在指定类型的任务下通过调用接口创建一个顺序节点，如"job-"。

2. 创建完成后，会返回一个完整的节点名，如"job-00000001"。

3. 客户端拼接type类型和返回值后，就可以作为全局唯一ID了，如"type2-job-00000001"。

 

分布式队列

　　分布式队列可以简单分为先入先出队列模型和等待队列元素聚集后统一安排处理执行的Barrier模型。

① FIFO先入先出，先进入队列的请求操作先完成后，才会开始处理后面的请求。FIFO队列就类似于全写的共享模型，所有客户端都会到/queue_fifo这个节点下创建一个临时节点，如/queue_fifo/host1-00000001。

　　创建完节点后，按照如下步骤执行。

1. 通过调用getChildren接口来获取/queue_fifo节点的所有子节点，即获取队列中所有的元素。

2. 确定自己的节点序号在所有子节点中的顺序。

3. 如果自己的序号不是最小，那么需要等待，同时向比自己序号小的最后一个节点注册Watcher监听。

4. 接收到Watcher通知后，重复步骤1。

② Barrier分布式屏障，最终的合并计算需要基于很多并行计算的子结果来进行，开始时，/queue_barrier节点已经默认存在，并且将结点数据内容赋值为数字n来代表Barrier值，之后，所有客户端都会到/queue_barrier节点下创建一个临时节点，例如/queue_barrier/host1。

　　创建完节点后，按照如下步骤执行。

1. 通过调用getData接口获取/queue_barrier节点的数据内容，如10。

2. 通过调用getChildren接口获取/queue_barrier节点下的所有子节点，同时注册对子节点变更的Watcher监听。

3. 统计子节点的个数。

4. 如果子节点个数还不足10个，那么需要等待。

5. 接受到Wacher通知后，重复步骤3。

 

 

Zookeeper服务端启动

 

Zookeeper的Leader选举