活着就是为了扭转世界，难道还有其余起因吗？——史蒂夫·乔布斯

ZooKeeper简介

ZooKeeper是一个开放源码的分布式应用程序协调服务，它蕴含一个简略的原语集，分布式应用程序能够基于它实现同步服务，配置保护和命名服务等。

ZooKeeper设计目标

  1. 最终一致性：client不管连贯到哪个Server，展现给它都是同一个视图，这是zookeeper最重要的性能。
  2. 可靠性：具备简略、强壮、良好的性能，如果音讯m被到一台服务器承受，那么它将被所有的服务器承受。
  3. 实时性：Zookeeper保障客户端将在一个工夫距离范畴内取得服务器的更新信息，或者服务器生效的信息。但因为网络延时等起因，Zookeeper不能保障两个客户端能同时失去刚更新的数据，如果须要最新数据，应该在读数据之前调用sync()接口。
  4. 期待无关（wait-free）：慢的或者生效的client不得干涉疾速的client的申请，使得每个client都能无效的期待。
  5. 原子性：更新只能胜利或者失败，没有中间状态。
  6. 程序性：包含全局有序和偏序两种：全局有序是指如果在一台服务器上音讯a在音讯b前公布，则在所有Server上音讯a都将在音讯b前被公布；偏序是指如果一个音讯b在音讯a后被同一个发送者公布，a必将排在b后面。

ZooKeeper数据模型

Zookeeper会保护一个具备档次关系的数据结构，它十分相似于一个规范的文件系统，如图所示：

Zookeeper这种数据结构有如下这些特点：

1）每个子目录项如NameService都被称作为znode，这个znode是被它所在的门路惟一标识，如Server1这个znode的标识为/NameService/Server1。

2）znode能够有子节点目录，并且每个znode能够存储数据，留神EPHEMERAL（长期的）类型的目录节点不能有子节点目录。

3）znode是有版本的（version），每个znode中存储的数据能够有多个版本，也就是一个拜访门路中能够存储多份数据，version号主动减少。

4）znode的类型：

  • Persistent 节点，一旦被创立，便不会意外失落，即便服务器全副重启也仍然存在。每个 Persist 节点即可蕴含数据，也可蕴含子节点。
  • Ephemeral 节点，在创立它的客户端与服务器间的 Session 完结时主动被删除。服务器重启会导致 Session 完结，因而 Ephemeral 类型的 znode 此时也会主动删除。
  • Non-sequence 节点，多个客户端同时创立同一 Non-sequence 节点时，只有一个可创立胜利，其它匀失败。并且创立出的节点名称与创立时指定的节点名齐全一样。
  • Sequence 节点，创立出的节点名在指定的名称之后带有10位10进制数的序号。多个客户端创立同一名称的节点时，都能创立胜利，只是序号不同。

5）znode能够被监控，包含这个目录节点中存储的数据的批改，子节点目录的变动等，一旦变动能够告诉设置监控的客户端，这个是Zookeeper的外围个性，Zookeeper的很多性能都是基于这个个性实现的。

6）ZXID：每次对Zookeeper的状态的扭转都会产生一个zxid（ZooKeeper Transaction Id），zxid是全局有序的，如果zxid1小于zxid2，则zxid1在zxid2之前产生。

ZooKeeper Session

Client和Zookeeper集群建设连贯，整个session状态变动如图所示：

如果Client因为Timeout和Zookeeper Server失去连贯，client处在CONNECTING状态，会主动尝试再去连贯Server，如果在session有效期内再次胜利连贯到某个Server，则回到CONNECTED状态。

留神：如果因为网络状态不好，client和Server失去分割，client会停留在以后状态，会尝试被动再次连贯Zookeeper Server。client不能声称本人的session expired，session expired是由Zookeeper Server来决定的，client能够抉择本人被动敞开session。

ZooKeeper Watch

Zookeeper watch是一种监听告诉机制。Zookeeper所有的读操作getData(), getChildren()和 exists()都能够设置监督(watch)，监督事件能够了解为一次性的触发器

官网定义如下：

a watch event is one-time trigger, sent to the client that set the watch, whichoccurs when the data for which the watch was set changes。

Watch的三个关键点：

（一次性触发）One-time trigger

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

（发送至客户端）Sent to the client

Zookeeper客户端和服务端是通过 socket 进行通信的，因为网络存在故障，所以监督事件很有可能不会胜利地达到客户端，监督事件是异步发送至监督者的，Zookeeper 自身提供了程序保障(ordering guarantee)：即客户端只有首先看到了监督事件后，才会感知到它所设置监督的znode产生了变动(a client will never see a change for which it has set a watch until it first sees the watch event)。

网络提早或者其余因素可能导致不同的客户端在不同的时刻感知某一监督事件，然而不同的客户端所看到的所有具备统一的程序。

（被设置 watch 的数据）The data for which the watch was set

这意味着znode节点自身具备不同的改变方式。你也能够设想 Zookeeper 保护了两条监督链表：数据监督和子节点监督(data watches and child watches) getData() 和exists()设置数据监督，getChildren()设置子节点监督。或者你也能够设想 Zookeeper 设置的不同监督返回不同的数据，getData() 和 exists() 返回znode节点的相干信息，而getChildren() 返回子节点列表。

因而，setData() 会触发设置在某一节点上所设置的数据监督（假设数据设置胜利），而一次胜利的create() 操作则会登程以后节点上所设置的数据监督以及父节点的子节点监督。一次胜利的 delete操作将会触发以后节点的数据监督和子节点监督事件，同时也会触发该节点父节点的child watch。

Zookeeper 中的监督是轻量级的，因而容易设置、保护和散发。当客户端与 Zookeeper 服务器失去分割时，客户端并不会收到监督事件的告诉，只有当客户端从新连贯后，若在必要的状况下，以前注册的监督会从新被注册并触发，对于开发人员来说这通常是通明的。

只有一种状况会导致监督事件的失落，即：通过exists()设置了某个znode节点的监督，然而如果某个客户端在此znode节点被创立和删除的工夫距离内与zookeeper服务器失去了分割，该客户端即便稍后从新连贯 zookeeper服务器后也得不到事件告诉。

Consistency Guarantees

Zookeeper是一个高效的、可扩大的服务，read和write操作都被设计为疾速的，read比write操作更快。

  • 程序一致性（Sequential Consistency）：从一个客户端来的更新申请会被程序执行。
  • 原子性（Atomicity）：更新要么胜利要么失败，没有局部胜利的状况。
  • 惟一的零碎镜像（Single System Image）：无论客户端连贯到哪个Server，看到零碎镜像是统一的。
  • 可靠性（Reliability）：更新一旦无效，继续无效，直到被笼罩。
  • 工夫线（Timeliness）：保障在肯定的工夫内各个客户端看到的零碎信息是统一的。

ZooKeeper的工作原理

在zookeeper的集群中，各个节点共有上面3种角色和4种状态：

  • 角色：leader,follower,observer
  • 状态：leading,following,observing,looking

Zookeeper的外围是原子播送，这个机制保障了各个Server之间的同步。实现这个机制的协定叫做Zab协定（ZooKeeper Atomic Broadcast protocol）。Zab协定有两种模式，它们别离是恢复模式（Recovery选主）和播送模式（Broadcast同步）。

当服务启动或者在领导者解体后，Zab就进入了恢复模式，当领导者被选举进去，且大多数Server实现了和leader的状态同步当前，恢复模式就完结了。状态同步保障了leader和Server具备雷同的零碎状态。

为了保障事务的程序一致性，zookeeper采纳了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上了zxid。

实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否扭转，每次一个leader被选出来，它都会有一个新的epoch，标识以后属于那个leader的统治期间。低32位用于递增计数。

每个Server在工作过程中有4种状态：

  • LOOKING：以后Server不晓得leader是谁，正在搜查。
  • LEADING：以后Server即为选举进去的leader。
  • FOLLOWING：leader曾经选举进去，以后Server与之同步。
  • OBSERVING：observer的行为在大多数状况下与follower完全一致，然而他们不加入选举和投票，而仅仅承受(observing)选举和投票的后果。

Leader Election

当leader解体或者leader失去大多数的follower，这时候zk进入恢复模式，恢复模式须要从新选举出一个新的leader，让所有的Server都复原到一个正确的状态。Zk的选举算法有两种：一种是基于basic paxos实现的，另外一种是基于fast paxos算法实现的。零碎默认的选举算法为fast paxos。先介绍basic paxos流程：

  1. 选举线程由以后Server发动选举的线程负责，其次要性能是对投票后果进行统计，并选出举荐的Server；
  2. 选举线程首先向所有Server发动一次询问（包含本人）；
  3. 选举线程收到回复后，验证是否是本人发动的询问（验证zxid是否统一），而后获取对方的id（myid），并存储到以后询问对象列表中，最初获取对方提议的leader相干信息（id,zxid），并将这些信息存储到当次选举的投票记录表中；
  4. 收到所有Server回复当前，就计算出zxid最大的那个Server，并将这个Server相干信息设置成下一次要投票的Server；
  5. 线程将以后zxid最大的Server设置为以后Server要举荐的Leader，如果此时获胜的Server取得n/2 + 1的Server票数，设置以后举荐的leader为获胜的Server，将依据获胜的Server相干信息设置本人的状态，否则，持续这个过程，直到leader被选举进去。

通过流程剖析咱们能够得出：要使Leader取得少数Server的反对，则Server总数必须是奇数2n+1，且存活的Server的数目不得少于n+1.

每个Server启动后都会反复以上流程。在恢复模式下，如果是刚从解体状态复原的或者刚启动的server还会从磁盘快照中复原数据和会话信息，zk会记录事务日志并定期进行快照，不便在复原时进行状态复原。

fast paxos流程是在选举过程中，某Server首先向所有Server提议本人要成为leader，当其它Server收到提议当前，解决epoch和zxid的抵触，并承受对方的提议，而后向对方发送承受提议实现的音讯，反复这个流程，最初肯定能选举出Leader。

Leader工作流程

Leader次要有三个性能：

  1. 复原数据；
  2. 维持与follower的心跳，接管follower申请并判断follower的申请音讯类型；
  3. follower的音讯类型次要有PING音讯、REQUEST音讯、ACK音讯、REVALIDATE音讯，依据不同的音讯类型，进行不同的解决。

阐明：

PING音讯是指follower的心跳信息；REQUEST音讯是follower发送的提议信息，包含写申请及同步申请；
ACK音讯是follower的对提议的回复，超过半数的follower通过，则commit该提议；
REVALIDATE音讯是用来缩短SESSION无效工夫。

Follower工作流程

Follower次要有四个性能：

  1. 向Leader发送申请（PING音讯、REQUEST音讯、ACK音讯、REVALIDATE音讯）；
  2. 接管Leader音讯并进行解决；
  3. 接管Client的申请，如果为写申请，发送给Leader进行投票；
  4. 返回Client后果。

Follower的音讯循环解决如下几种来自Leader的音讯：

  1. PING音讯：心跳音讯
  2. PROPOSAL音讯：Leader发动的提案，要求Follower投票
  3. COMMIT音讯：服务器端最新一次提案的信息
  4. UPTODATE音讯：表明同步实现
  5. REVALIDATE音讯：依据Leader的REVALIDATE后果，敞开待revalidate的session还是容许其承受音讯
  6. SYNC音讯：返回SYNC后果到客户端，这个音讯最后由客户端发动，用来强制失去最新的更新。

Zab: Broadcasting State Updates

Zookeeper Server接管到一次request，如果是follower，会转发给leader，Leader执行申请并通过Transaction的模式播送这次执行。Zookeeper集群如何决定一个Transaction是否被commit执行？通过“两段提交协定”（a two-phase commit）：

  • Leader给所有的follower发送一个PROPOSAL音讯。
  • 一个follower接管到这次PROPOSAL音讯，写到磁盘，发送给leader一个ACK音讯，告知曾经收到。
  • 当Leader收到法定人数（quorum）的follower的ACK时候，发送commit音讯执行。

Zab协定保障：

  • 如果leader以T1和T2的程序播送，那么所有的Server必须先执行T1，再执行T2。
  • 如果任意一个Server以T1、T2的程序commit执行，其余所有的Server也必须以T1、T2的程序执行。

“两段提交协定”最大的问题是如果Leader发送了PROPOSAL音讯后crash或临时失去连贯，会导致整个集群处在一种不确定的状态（follower不晓得该放弃这次提交还是执行提交）。Zookeeper这时会选出新的leader，申请解决也会移到新的leader上，不同的leader由不同的epoch标识。切换Leader时，须要解决上面两个问题：

1. Never forget delivered messages

Leader在COMMIT投递到任何一台follower之前crash，只有它本人commit了。新Leader必须保障这个事务也必须commit。

2. Let go of messages that are skipped

Leader产生某个proposal，然而在crash之前，没有follower看到这个proposal。该server复原时，必须抛弃这个proposal。

Zookeeper会尽量保障不会同时有2个流动的Leader，因为2个不同的Leader会导致集群处在一种不统一的状态，所以Zab协定同时保障：

  • 在新的leader播送Transaction之前，先前Leader commit的Transaction都会先执行。
  • 在任意时刻，都不会有2个Server同时有法定人数（quorum）的支持者。
    这里的quorum是一半以上的Server数目，确切的说是有投票势力的Server（不包含Observer）。

总结

简略介绍了Zookeeper的基本原理，数据模型，Session，Watch机制，一致性保障，Leader Election，Leader和Follower的工作流程和Zab协定。