Zookeeper基本概念

一、ZooKeeper是什么

ZooKeeper 是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。

二、ZooKeeper存储结构

节点（Znode）

在 Zookeeper 中，znode 是一个跟 Unix 文件系统路径相似的节点，可以往这个节点存储或获取数据。 Zookeeper 底层是一套数据结构。这个存储结构是一个树形结构，其上的每一个节点，我们称之为“znode” zookeeper 中的数据是按照“树”结构进行存储的。而且 znode 节点还分为 4 中不同的类型。每一个 znode 默认能够存储 1MB 的数据（对于记录状态性质的数据来说，够了）可以使用 zkCli 命令，登录到 zookeeper 上，并通过 ls、create、delete、get、set 等命令操作这些 znode 节点。每一个 znode 默认能够存储 1MB 的数据。 创建znode时设置顺序标识，znode名称后会附加一个值，顺序号是一个单调递增的计数器，由父节点维护；在分布式系统中，顺序号可以被用于为所有的事件进行全局排序，这样客户端可以通过顺序号推断事件的顺序

znode的类型

PERSISTENT-持久化目录节点

客户端与zookeeper断开连接后，该节点依旧存在
PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点

客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号
EPHEMERAL-临时目录节点

客户端与zookeeper断开连接后，该节点被删除
EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点

客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号

节点信息

每一个Znode都有对应的stat结构，和文件系统类似。可以使用ls2和stat命令查看ZooKeeper节点下的信息。stat状态主要包含下面的信息：

属性	解释
cZxid	节点被创建时候的事务ID
mZxid	节点最后一次被修改时候的事务ID
pZxid	该节点的子节点最后一次被修改时的事务ID。子节点删除或添加才会影响pZxid
ctime	节点被创建的时间
mtime	节点被修改的世界
dataVersion	这个节点数据改变的次数
cversion	子节点被改变的次数
aclVersion	节点的ACL(访问控制列表被改变的次数)
ephemeralOwner	创建该临时节点的 session ID。如果是持久节点，设置为0
dataLength	数据内容长度
numChildren	当前节点子节点的个数

节点的访问控制(ACL)

zk提供了ACL来控制znode节点的访问，只有符合了ACL控制,才可以操作该节点，否则将无法操作。
Zookeeper支持可配置的认证机制。它利用一个三元组来定义客户端的访问权限：
(scheme:expression, perms) 。其中：

Schema 代表权限控制模式，分别为：
● World 任何人
● Auth 不需要ID
● Digest 用户名和密码方式的认证
● IP Address IP地址方式的认证
perms(权限)，ZooKeeper支持如下权限
● CREATE: 创建子节点
● READ：获取子节点与自身节点的数据信息
● WRITE：在Znode节点上写数据
● DELETE：删除子节点
● ADMIN：设置ACL权限

注意：
Znode的Acl只是针对某个节点，不会作用到它的子节点上
任何连接到ZooKeeper的客户端都可以使用exist操作，exist是不需要权限的。

三、Zookeeper 集群中的角色

集群角色

在ZooKeeper中，有三种角色：

Leader
Follower(learner)
Observer(learner)
Client

ZooKeeper集群的所有机器通过一个Leader选举过程来选定一台被称为**『Leader』的机器，Leader服务器为客户端提供读和写**服务。更新系统状态。

Follower和Observer都能提供读服务，不能提供写服务。两者唯一的区别在于，Observer机器不参与Leader选举过程，也不参与写操作的『过半写成功』策略，因此Observer可以在不影响写性能的情况下提升集群的读性能。

Server状态

leading --当前Server即为选举出来的leader。
following --leader已经选举出来，当前Server与之同步。
observing --observer的行为在大多数情况下与follower完全一致，但是他们不参加选举和投票，而仅仅接受(observing)选举和投票的结果。
looking – 当前Server不知道leader是谁，正在搜寻。

四、Zookeeper 工作原理

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

当服务启动或者在Leader崩溃后，zk集群进入崩溃恢复模式，当Leader被选举处理，同时集群中已经有过半的机器与该Leader服务器完成状态同步（数据同步），zk集群退出崩溃恢复模式，进入消息广播模式。当新加入一台机器到集群中，如果此时集群已经存在一个Leader服务器在负责进行消息广播，那么新加入的服务器就会自觉地进入数据恢复模式，找到Leader服务器，并与其进行数据同步，然后进入消息广播模式。

Zookeeper在崩溃恢复模式中，通过选举机制产生一个Leader，多个Flollower。而监听机制是zookeeper对于应用最重要的特性。接下来重点介绍选举机制和监听机制。

zookeeper的选举机制（全新集群paxos）

假设有五台服务器组成的zookeeper集群，它们的id从1-5,同时它们都是最新启动的，也就是没有历史数据,在存放数据量这一点上，都是一样的。假设这些服务器依序启动，来看看会发生什么。

1)、服务器1启动，此时只有它一台服务器启动了，它发出去的报没有任何响应，所以它的选举状态一直是LOOKING状态；
2)、服务器2启动，它与最开始启动的服务器1进行通信，互相交换自己的选举结果，由于两者都没有历史数据，所以id值较大的服务器2胜出，但是由于没有达到超过半数以上的服务器都同意选举它(这个例子中的半数以上是3)，所以服务器1、2还是继续保持LOOKING状态；
3)、服务器3启动，根据前面的理论分析，服务器3成为服务器1、2、3中的老大，而与上面不同的是，此时有三台服务器选举了它，所以它成为了这次选举的leader；
4)、服务器4启动，根据前面的分析，理论上服务器4应该是服务器1、2、3、4中最大的，但是由于前面已经有半数以上的服务器选举了服务器3，所以它只能接收当小弟的命了；
5)、服务器5启动，同4一样,当小弟。

非全新集群的选举机制（数据恢复）

那么，初始化的时候，是按照上述的说明进行选举的，但是当zookeeper运行了一段时间之后，有机器down掉，重新选举时，选举过程就相对复杂了。需要加入数据id、leader id和逻辑时钟。

数据id：数据新的id就大，数据每次更新都会更新id。
Leader id：就是我们配置的myid中的值，每个机器一个。
逻辑时钟：这个值从0开始递增，每次选举对应一个值，也就是说：如果在同一次选举中，那么这个值应该是一致的；逻辑时钟值越大，说明这一次选举leader的进程更新。

选举的标准就变成：
1、逻辑时钟小的选举结果被忽略，重新投票
2、统一逻辑时钟后，数据id大的胜出
3、数据id相同的情况下，leader id大的胜出

根据这个规则选出leader。

zookeeper的watch机制

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

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

zookeeper机制的特点：

1）一次性的触发器

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

2）主动发送给客户端

Watch的通知事件是从服务器发送给客户端的，是异步的，这就表明不同的客户端收到的Watch的时间可能不同，但是ZooKeeper有保证：客户端只有首先看到了监视事件后，才会感知到它所设置监视的znode节点数据发生了变化。例如：A=3，此时在上面设置了一次Watch，如果A突然变成了4，那么客户端会先收到Watch事件的通知，然后才会看到A=4。zookeeper客户端和服务端是通过Socket进行通信的，由于网络延迟或者其他因素可能导致不同的客户端在不同的时刻感知某一监视事件，但是不同的客户端所看到的一切具有一致的顺序。