zookeeper基本讲解

1.什么是zookeeper

zookeeper:是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop的重要组件，CDH版本中更是使用它进行Namenode的协调控制。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、名字服务、分布式同步、组服务等。ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。

2.基本概念

角色：
zookeeper主要有以下角色：

Leader(领导者) 为客户端提供读和写的服务，负责投票的发起和决议，更新系统状态。Follower（跟随者）   为客户端提供读服务，如果是写服务则转发给Leader。在选举过程中参与投票。Observe（观察者）    为客户端提供读服务器，如果是写服务则转发给Leader。不参与选举过程中的投票，也不参与“过半写成功”策略。在不影响写性能的情况下提升集群的读性能。此角色于zookeeper3.3系列新增的角色。client（客户端） 连接zookeeper服务器的使用着，请求的发起者。独立于zookeeper服务器集群之外的角色。

各个角色的关系:

---

系统模型:
——-1.1数据模型:
Zookeeper的数据节点称为ZNode，ZNode是Zookeeper中数据的最小单元，每个ZNode都可以保存数据，同时还可以挂载子节点，因此构成了一个层次化的命名空间，称为树。

在Zookeeper中，事务是指能够改变Zookeeper服务器状态的操作，一般包括节点创建与删除，数据节点内容更新和客户端会话创建与失效，对于每个事务请求，Zookeeper都会为其分配一个全局唯一的事务ID，用ZXID表示，通常是64位的数字，每个ZXID对应一次更新操作，从这些ZXID中可以间接地识别出Zookeeper处理这些更新操作请求的全局顺序。

znode除了名称、数据以外，还有一套属性：zxid。这套zid与时间戳对应，记录zid不同的状态

---

—–1.2节点的特性：

在Zookeeper中，每个数据节点都是由生命周期的，类型不同则会不同的生命周期，节点类型可以分为持久节点（PERSISTENT）、临时节点（EPHEMERAL）、顺序节点（SEQUENTIAL）三大类，可以通过组合生成如下四种类型节点

　　1. 持久节点（PERSISTENT）。节点创建后便一直存在于Zookeeper服务器上，直到有删除操作来主动清楚该节点。

　　2. 持久顺序节点（PERSISTENT_SEQUENTIAL）。相比持久节点，其新增了顺序特性，每个父节点都会为它的第一级子节点维护一份顺序，用于记录每个子节点创建的先后顺序。在创建节点时，会自动添加一个数字后缀，作为新的节点名，该数字后缀的上限是整形的最大值。

　　3. 临时节点（EPEMERAL）。临时节点的生命周期与客户端会话绑定，客户端失效，节点会被自动清理。同时，Zookeeper规定不能基于临时节点来创建子节点，即临时节点只能作为叶子节点。

　　4. 临时顺序节点（EPEMERAL_SEQUENTIAL）。在临时节点的基础添加了顺序特性。

　　每个节点除了存储数据外，还存储了节点本身的一些状态信息，可通过get命令获取。

---

—–1.3 get获取信息的数据解释:

czxid：创建节点的事务的zxid
mzxid：对znode最近修改的zxid
ctime：以距离时间原点(epoch)的毫秒数表示的znode创建时间
mtime：以距离时间原点(epoch)的毫秒数表示的znode最近修改时间
version：znode数据的修改次数
cversion：znode子节点修改次数
aversion：znode的ACL修改次数
ephemeralOwner：如果znode是临时节点，则指示节点所有者的会话ID；如果不是临时节点，则为零。
dataLength：znode数据长度。
numChildren：znode子节点个数。

---

—–1.4保证分布式数据原子性操作

dataVersion– 当前数据节点数据内容的版本号
cversion– 当前数据子节点的版本号
aclVersion– 当前数据节点ACL变更版本号

---

—–1.5Watcher–数据变更通知
Zookeeper使用Watcher机制实现分布式数据的发布/订阅功能。

Zookeeper的Watcher机制主要包括客户端线程、客户端WatcherManager、Zookeeper服务器三部分。客户端在向Zookeeper服务器注册的同时，会将Watcher对象存储在客户端的WatcherManager当中。当Zookeeper服务器触发Watcher事件后，会向客户端发送通知，客户端线程从WatcherManager中取出对应的Watcher对象来执行回调逻辑。

---

—1.6ACL–保障数据的安全

Zookeeper内部存储了分布式系统运行时状态的元数据，这些元数据会直接影响基于Zookeeper进行构造的分布式系统的运行状态，如何保障系统中数据的安全，从而避免因误操作而带来的数据随意变更而导致的数据库异常十分重要，Zookeeper提供了一套完善的ACL权限控制机制来保障数据的安全。　　我们可以从三个方面来理解ACL机制：权限模式（Scheme）、授权对象（ID）、权限（Permission），通常使用"scheme:id:permission"来标识一个有效的ACL信息。　　权限模式用来确定权限验证过程中使用的检验策略，有如下四种模式：　　1. IP，通过IP地址粒度来进行权限控制，如"ip:192.168.0.110"表示权限控制针对该IP地址，同时IP模式可以支持按照网段方式进行配置，如"ip:192.168.0.1/24"表示针对192.168.0.*这个网段进行权限控制。　　2. Digest，使用"username:password"形式的权限标识来进行权限配置，便于区分不同应用来进行权限控制。Zookeeper会对其进行SHA-1加密和BASE64编码。　　3. World，最为开放的权限控制模式，数据节点的访问权限对所有用户开放。　　4. Super，超级用户，是一种特殊的Digest模式，超级用户可以对任意Zookeeper上的数据节点进行任何操作。　　授权对象是指权限赋予的用户或一个指定实体，如IP地址或机器等。不同的权限模式通常有不同的授权对象。　　权限是指通过权限检查可以被允许执行的操作，Zookeeper对所有数据的操作权限分为CREATE（节点创建权限）、DELETE（节点删除权限）、READ（节点读取权限）、WRITE（节点更新权限）、ADMIN（节点管理权限）。

---

—1.7数据结构

Zookeeper 这种数据结构有如下这些特点：    每个子目录项如 NameService 都被称作为 znode，这个 znode 是被它所在的路径唯一标识，如 Server1 这个 znode 的标识为 /NameService/Server1    znode 可以有子节点目录，并且每个 znode 可以存储数据，注意 EPHEMERAL 类型的目录节点不能有子节点目录    znode 是有版本的，每个 znode 中存储的数据可以有多个版本，也就是一个访问路径中可以存储多份数据    znode 可以是临时节点，一旦创建这个 znode 的客户端与服务器失去联系，这个 znode 也将自动删除，Zookeeper 的客户端和服务器通信采用长连接方式，每个客户端和服务器通过心跳来保持连接，这个连接状态称为 session，如果 znode 是临时节点，这个 session 失效，znode 也就删除了    znode 的目录名可以自动编号，如 App1 已经存在，再创建的话，将会自动命名为 App2    znode 可以被监控，包括这个目录节点中存储的数据的修改，子节点目录的变化等，一旦变化可以通知设置监控的客户端，这个是 Zookeeper 的核心特性，Zookeeper 的很多功能都是基于这个特性实现的，后面在典型的应用场景中会有实例介绍

选举算法

1.1 fast paxos

    全天下我最牛，在我没有发现比我牛的推荐人的情况下，我就一直推举我当leader。第一次投票那必须推举我自己当leader。    每当我接收到其它的被推举者，我都要回馈一个信息，表明我还是不是推举我自己。如果被推举者没我大，我就一直推举我当leader，是我是我还是我！    我有一个票箱， 和我属于同一轮的投票情况都在这个票箱里面。一人一票 重复的或者过期的票，我都不接受。    一旦我不再推举我自己了（这时我发现别人推举的人比我推荐的更牛），我就把我的票箱清空，重新发起一轮投票（这时我的票箱一定有两票了，都是选的我认为最牛的人）。    一旦我发现收到的推举信息中投票轮要高于我的投票轮，我也要清空我的票箱。并且还是投当初我觉得最牛的那个人（除非当前的人比我最初的推荐牛，我就顺带更新我的推荐）。    不断的重复上面的过程，不断的告诉别人“我的投票是第几轮”、“我推举的人是谁”。直到我的票箱中“我推举的最牛的人”收到了不少于 N /2 + 1的推举投票。    这时我就可以决定我是flower还是leader了（如果至始至终都是我最牛，那我就是leader咯，其它情况就是follower咯）。并且不论随后收到谁的投票，都向它直接反馈“我的结果”

---

2.2 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被选举出来。

4.watcher机制

Zookeeper 监视（Watches） 简介Zookeeper C API 的声明和描述在 include/zookeeper.h 中可以找到，另外大部分的 Zookeeper C API 常量、结构体声明也在 zookeeper.h 中，如果如果你在使用 C API 是遇到不明白的地方，最好看看 zookeeper.h，或者自己使用 doxygen 生成 Zookeeper C API 的帮助文档。Zookeeper 中最有特色且最不容易理解的是监视(Watches)。Zookeeper 所有的读操作——getData(), getChildren(), 和 exists() 都 可以设置监视(watch)，监视事件可以理解为一次性的触发器， 官方定义如下： a watch event is one-time trigger, sent to the client that set the watch, which occurs when the data for which the watch was set changes。对此需要作出如下理解：（一次性触发）One-time trigger当设置监视的数据发生改变时，该监视事件会被发送到客户端，例如，如果客户端调用了 getData("/znode1", true) 并且稍后 /znode1 节点上的数据发生了改变或者被删除了，客户端将会获取到 /znode1 发生变化的监视事件，而如果 /znode1 再一次发生了变化，除非客户端再次对 /znode1 设置监视，否则客户端不会收到事件通知。（发送至客户端）Sent to the clientZookeeper 客户端和服务端是通过 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() and exists() 设置数据监视，getChildren() 设置子节点监视。 或者，你也可以想象 Zookeeper 设置的不同监视返回不同的数据，getData() 和 exists() 返回 znode 节点的相关信息，而 getChildren() 返回子节点列表。因此， setData() 会触发设置在某一节点上所设置的数据监视(假定数据设置成功)，而一次成功的 create() 操作则会出发当前节点上所设置的数据监视以及父节点的子节点监视。一次成功的 delete() 操作将会触发当前节点的数据监视和子节点监视事件，同时也会触发该节点父节点的child watch。

Zookeeper 中的监视是轻量级的，因此容易设置、维护和分发。当客户端与 Zookeeper 服务器端失去联系时，客户端并不会收到监视事件的通知，只有当客户端重新连接后，若在必要的情况下，以前注册的监视会重新被注册并触发，对于开发人员来说 这通常是透明的。只有一种情况会导致监视事件的丢失，即：通过 exists() 设置了某个 znode 节点的监视，但是如果某个客户端在此 znode 节点被创建和删除的时间间隔内与 zookeeper 服务器失去了联系，该客户端即使稍后重新连接 zookeeper服务器后也得不到事件通知

zookeeper中的watcher机制很特别，请注意以下一些关键的经验提醒（这些经验提醒在其他地方找不到）：一个节点可以注册多个watcher，但是分成两种情况，当一个watcher实例多次注册时，zkClient也只会通知一次；当多个不同的watcher实例都注册时，zkClient会依次进行通知（并不是很多网贴粗略说的“多次注册一次通知”），后文将会有实验。监控同一个节点X的一个watcher实例，通过exist、getData等注册方式多次注册的，zkClient也只会通知一次。这个原理在很多网贴上也都有说明，后文我们同样进行实验。注意，很多网贴都说zk.getData(“/node-x”,watcher)这种注册方式可以监控节点的NodeCreated事件，实际上是不行的（或者说没有意义）。当一个节点还不存在时，zk.getData这样设置的watcher是会抛出KeeperException$NoNodeException异常的，这次注册会失败，watcher也不会起作用；一旦node-x节点存在了，那这个节点的NodeCreated事件又有什么意义呢？（后文做实验）zookeeper中并没有“永久监听”这种机制。网上所谓实现了”永久监听”的帖子，只是一种编程技巧。思路可以归为两类：一种是“在保证所有节点的watcher都被重新注册”的前提下，再进行目录、子目录的更改；另外一种是“在监听被触发后，被重新注册前，重新取一次节点的信息”确保在“监听真空期”znode没有变化。 有兴趣的读者可自行百度。

zookeeper工作原理：

    Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。    为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，标识当前属于那个leader的统治时期。低32位用于递增计数。每个Server在工作过程中有三种状态：LOOKING：当前Server不知道leader是谁，正在搜寻LEADING：当前Server即为选举出来的leaderFOLLOWING：leader已经选举出来，当前Server与之同步

同步

选完leader以后，zk就进入状态同步过程。    1. leader等待server连接；    2 .Follower连接leader，将最大的zxid发送给leader；    3 .Leader根据follower的zxid确定同步点；    4 .完成同步后通知follower 已经成为uptodate状态；    5 .Follower收到uptodate消息后，又可以重新接受client的请求进行服务了

流程图：

leader工作流程：
Leader主要有三个1 .恢复数据；

2 .维持与Learner的心跳，接收Learner请求并判断Learner的请求消息类型；

3 .Learner的消息类型主要有PING消息、REQUEST消息、ACK消息、REVALIDATE消息，根据不同的消息类型，进行不同的处理。

PING消息是指Learner的心跳信息；REQUEST消息是Follower发送的提议信息，包括写请求及同步请求；ACK消息是Follower的对提议的回复，超过半数的Follower通过，则commit该提议；REVALIDATE消息是用来延长SESSION有效时间。——-
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结果到客户端，这个消息最初由客户端发起，用来强制得到最新的更新。

zookeeper应用场景

1.数据发布与订阅 （我的业务用到这个特性，后面会有详细介绍）应用配置集中到节点上，应用启动时主动获取，并在节点上注册一个watcher，每次配置更新都会通知到应用。2.名空间服务分布式命名服务，创建一个节点后，节点的路径就是全局唯一的，可以作为全局名称使用。3.分布式通知/协调不同的系统都监听同一个节点，一旦有了更新，另一个系统能够收到通知。4.分布式锁Zookeeper能保证数据的强一致性，用户任何时候都可以相信集群中每个节点的数据都是相同的。一个用户创建一个节点作为锁，另一个用户检测该节点，如果存在，代表别的用户已经锁住，如果不存在，则可以创建一个节点，代表拥有一个锁。 5.集群管理每个加入集群的机器都创建一个节点，写入自己的状态。监控父节点的用户会受到通知，进行相应的处理。离开时删除节点，监控父节点的用户同样会收到通知。

Zookeeper的主流应用场景实现思路（除去官方示例):

(1)配置管理
集中式的配置管理在应用集群中是非常常见的，一般商业公司内部都会实现一套集中的配置管理中心，应对不同的应用集群对于共享各自配置的需求，并且在配置变更时能够通知到集群中的每一个机器。

Zookeeper很容易实现这种集中式的配置管理，比如将APP1的所有配置配置到/APP1 znode下，APP1所有机器一启动就对/APP1这个节点进行监控(zk.exist(“/APP1”,true)),并且实现回调方法Watcher，那么在zookeeper上/APP1 znode节点下数据发生变化的时候，每个机器都会收到通知，Watcher方法将会被执行，那么应用再取下数据即可(zk.getData(“/APP1”,false,null));

以上这个例子只是简单的粗颗粒度配置监控，细颗粒度的数据可以进行分层级监控，这一切都是可以设计和控制的。

---

(2)集群管理
应用集群中，我们常常需要让每一个机器知道集群中（或依赖的其他某一个集群）哪些机器是活着的，并且在集群机器因为宕机，网络断链等原因能够不在人工介入的情况下迅速通知到每一个机器。

Zookeeper同样很容易实现这个功能，比如我在zookeeper服务器端有一个znode叫/APP1SERVERS,那么集群中每一个机器启动的时候都去这个节点下创建一个EPHEMERAL类型的节点，比如server1创建/APP1SERVERS/SERVER1(可以使用ip,保证不重复)，server2创建/APP1SERVERS/SERVER2，然后SERVER1和SERVER2都watch /APP1SERVERS这个父节点，那么也就是这个父节点下数据或者子节点变化都会通知对该节点进行watch的客户端。因为EPHEMERAL类型节点有一个很重要的特性，就是客户端和服务器端连接断掉或者session过期就会使节点消失，那么在某一个机器挂掉或者断链的时候，其对应的节点就会消失，然后集群中所有对/APP1SERVERS进行watch的客户端都会收到通知，然后取得最新列表即可。

另外有一个应用场景就是集群选master,一旦master挂掉能够马上能从slave中选出一个master,实现步骤和前者一样，只是机器在启动的时候在APP1SERVERS创建的节点类型变为EPHEMERAL_SEQUENTIAL类型，这样每个节点会自动被编号

我们默认规定编号最小的为master,所以当我们对/APP1SERVERS节点做监控的时候，得到服务器列表，只要所有集群机器逻辑认为最小编号节点为master，那么master就被选出，而这个master宕机的时候，相应的znode会消失，然后新的服务器列表就被推送到客户端，然后每个节点逻辑认为最小编号节点为master，这样就做到动态master选举。

Zookeeper在大型分布式系统中的应用:
http://www.cnblogs.com/leesf456/p/6063694.html

参考：
http://www.cnblogs.com/leesf456/p/6072597.html
http://blog.csdn.net/wo541075754/article/details/60316543
http://blog.csdn.net/guchuanyun111/article/details/52091318
http://blog.csdn.net/guchuanyun111/article/details/52091406