ZooKeeper

一、ZooKeeper是什么？

官方文档上这么解释zookeeper，它是一个分布式服务框架，是Apache Hadoop 的一个子项目，它主要是用来解决分布式应用中经常遇到的一些数据管理问题，如：统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。

ZooKeeper 是一个典型的分布式数据一致性解决方案，分布式应用程序可以基于 ZooKeeper 实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。

简单来说zookeeper=文件系统+监听通知机制。

1.1 文件系统

每个子目录项如 NameService 都被称作为 znode(目录节点)，和文件系统一样，我们能够自由的增加、删除、增加znode，支持嵌套，唯一的不同在于znode是可以存储数据的。

ZooKeeper 将所有数据存储在内存中，数据模型是一棵树(Znode Tree)，由斜杠(/)的进行分割的路径，就是一个 Znode，例如/NameService/Server1。每个上都会保存自己的数据内容，同时还会保存一系列属性信息。

有四种类型的znode：
1.PERSISTENT(持久化目录节点)
客户端与zookeeper断开连接后，该节点依旧存在

2.PERSISTENT_SEQUENTIAL(持久化顺序编号目录节点)
客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号

3.EPHEMERAL(临时目录节点)
客户端与zookeeper断开连接后，该节点被删除

4.EPHEMERAL_SEQUENTIAL(临时顺序编号目录节点)
客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号

1.2 监听通知机制

客户端注册监听它关心的目录节点，当目录节点发生变化(数据改变、被删除、子目录节点增加删除)时，zookeeper会通知客户端。

1.3 关于ZooKeeper的一些重要概念

ZooKeeper 本身就是一个分布式程序(只要半数以上节点存活，ZooKeeper 就能正常服务)。

为了保证高可用，最好是以集群形态来部署 ZooKeeper，这样只要集群中大部分机器是可用的(能够容忍一定的机器故障)，那么 ZooKeeper 本身仍然是可用的。

ZooKeeper 将数据保存在内存中，这也就保证了 高吞吐量和低延迟(但是内存限制了能够存储的容量不太大，此限制也是保持 Znode 中存储的数据量较小的进一步原因)。

ZooKeeper 是高性能的。在“读”多于“写”的应用程序中尤其地高性能，因为“写”会导致所有的服务器间同步状态。(“读”多于“写”是协调服务的典型场景。)

ZooKeeper 有临时节点的概念。当创建临时节点的客户端会话一直保持活动，瞬时节点就一直存在。

而当会话终结时，瞬时节点被删除。持久节点是指一旦这个 ZNode 被创建了，除非主动进行 ZNode 的移除操作，否则这个 ZNode 将一直保存在 Zookeeper 上。

ZooKeeper 底层其实只提供了两个功能：①管理(存储、读取)用户程序提交的数据；②为用户程序提交数据节点监听服务。

在 ZooKeeper 中 Leader 选举算法采用了 Zab 协议。Zab 核心思想是当多数 Server 写成功，则任务数据写成功：
如果有 3 个 Server，则最多允许 1 个 Server 挂掉。
如果有 4 个 Server，则同样最多允许 1 个 Server 挂掉。
既然 3 个或者 4 个 Server，同样最多允许 1 个 Server 挂掉，那么它们的可靠性是一样的。
所以选择奇数个 ZooKeeper Server 即可，这里选择 3 个 Server。

二、Zookeeper使用

和Linux文件系统一样，使用ls命令可以查看所有的ZNode节点，新安装的Zookeeper下可以看到只有根节点：

使用 create /zkPro myData在根节点下创建一个新ZNode：

下面我们运行 get 命令来确认上面所创建的 znode 是否包含我们所创建的字符串：

通过 set 命令来对 zk 所关联的字符串进行设置：

将刚才创建的 znode 删除：

三、ZNode数据

3.1 Stat结构体

Zookeeper 的每个 ZNode 上都会存储数据，对应于每个 ZNode，Zookeeper 都会为其维护一个叫作 Stat 的数据结构。
Stat 中记录了这个 ZNode 的三个数据版本，分别是：
dataversion(当前 ZNode 的版本)
cversion(当前 ZNode 子节点的版本)
aclversion(当前 ZNode 的 ACL 版本)

3.2 ACL

ZooKeeper 采用 ACL(AccessControlLists)策略来进行权限控制，类似于 UNIX 文件系统的权限控制。
ZooKeeper 定义了 5 种权限，如下图：

四、ZooKeeper集群

4.1 ZooKeeper集群角色介绍

最典型集群模式：Master/Slave 模式(主备模式)。在这种模式中，通常 Master 服务器作为主服务器提供写服务，其他的 Slave 服务器从服务器通过异步复制的方式获取 Master 服务器最新的数据提供读服务。
但是，在 ZooKeeper 中没有选择传统的 Master/Slave 概念，而是引入了Leader、Follower 和 Observer 三种角色。

ZooKeeper 集群中的所有机器通过一个 Leader 选举过程来选定一台称为 “Leader” 的机器。
Leader 既可以为客户端提供写服务又能提供读服务。除了 Leader 外，Follower 和 Observer 都只能提供读服务。
Follower 和 Observer 唯一的区别在于 Observer 机器不参与 Leader 的选举过程，也不参与写操作的“过半写成功”策略，因此 Observer 机器可以在不影响写性能的情况下提升集群的读性能。

4.2 Zookeeper集群模式安装

本例搭建的是伪集群模式，即一台机器上启动三个zookeeper实例组成集群，真正的集群模式无非就是实例IP地址不同，搭建方法没有区别。

Step1：配置JAVA环境，检验环境：java -versionStep2：下载并解压zookeeper

# cd /usr/local
# wget http://mirror.bit.edu.cn/apache/zookeeper/stable/zookeeper-3.4.12.tar.gz
# tar -zxvf zookeeper-3.4.12.tar.gz
# cd zookeeper-3.4.12

Step3：重命名 zoo_sample.cfg文件

# cp conf/zoo_sample.cfg conf/zoo-1.cfg

Step4：修改配置文件zoo-1.cfg，原配置文件里有的，修改成下面的值，没有的则加上

# vim conf/zoo-1.cfg
dataDir=/tmp/zookeeper-1
clientPort=2181
server.1=127.0.0.1:2888:3888
server.2=127.0.0.1:2889:3889
server.3=127.0.0.1:2890:3890

配置说明
tickTime：这个时间是作为 Zookeeper 服务器之间或客户端与服务器之间维持心跳的时间间隔，也就是每个 tickTime 时间就会发送一个心跳。
initLimit：这个配置项是用来配置 Zookeeper 接受客户端(这里所说的客户端不是用户连接 Zookeeper 服务器的客户端，而是 Zookeeper 服务器集群中连接到 Leader 的 Follower 服务器)初始化连接时最长能忍受多少个心跳时间间隔数。当已经超过 10个心跳的时间(也就是 tickTime)长度后 Zookeeper 服务器还没有收到客户端的返回信息，那么表明这个客户端连接失败。总的时间长度就是 10*2000=20 秒
syncLimit：这个配置项标识 Leader 与 Follower 之间发送消息，请求和应答时间长度，最长不能超过多少个 tickTime 的时间长度，总的时间长度就是 5*2000=10秒
dataDir：顾名思义就是 Zookeeper 保存数据的目录，默认情况下，Zookeeper 将写数据的日志文件也保存在这个目录里。
clientPort：这个端口就是客户端连接 Zookeeper 服务器的端口，Zookeeper 会监听这个端口，接受客户端的访问请求。
server.A=B：C：D：其中 A 是一个数字，表示这个是第几号服务器；B 是这个服务器的 ip 地址；C 表示的是这个服务器与集群中的 Leader 服务器交换信息的端口；D 表示的是万一集群中的 Leader 服务器挂了，需要一个端口来重新进行选举，选出一个新的 Leader，而这个端口就是用来执行选举时服务器相互通信的端口。如果是伪集群的配置方式，由于 B 都是一样，所以不同的 Zookeeper 实例通信端口号不能一样，所以要给它们分配不同的端口号。

Step5：再从zoo-1.cfg复制两个配置文件zoo-2.cfg和zoo-3.cfg，只需修改dataDir和clientPort不同即可

# cp conf/zoo-1.cfg conf/zoo-2.cfg
# cp conf/zoo-1.cfg conf/zoo-3.cfg
# vim conf/zoo-2.cfg
dataDir=/tmp/zookeeper-2
clientPort=2182
# vim conf/zoo-2.cfg
dataDir=/tmp/zookeeper-3
clientPort=2183

Step6：标识Server ID
创建三个文件夹/tmp/zookeeper-1，/tmp/zookeeper-2，/tmp/zookeeper-2，在每个目录中创建文件myid 文件，写入当前实例的server id，即1.2.3

# cd /tmp/zookeeper-1
# vim myid
1
# cd /tmp/zookeeper-2
# vim myid
2
# cd /tmp/zookeeper-3
# vim myid
3

Step7：启动三个zookeeper实例

# bin/zkServer.sh start conf/zoo-1.cfg
# bin/zkServer.sh start conf/zoo-2.cfg
# bin/zkServer.sh start conf/zoo-3.cfg

Step8：检测集群状态，也可以直接用命令“zkCli.sh -server IP:PORT”连接zookeeper服务端检测

五、ZooKeeper实现分布式锁

5.1 ZooKeeper的每一个节点，都是一个天然的顺序发号器

在每一个节点下面创建临时顺序节点(EPHEMERAL_SEQUENTIAL)类型，新的子节点后面，会加上一个次序编号，而这个生成的次序编号，是上一个生成的次序编号加一。
例如，有一个用于发号的节点“/test/lock”为父亲节点，可以在这个父节点下面创建相同前缀的临时顺序子节点，假定相同的前缀为“/test/lock/seq-”。第一个创建的子节点基本上应该为/test/lock/seq-0000000000，下一个节点则为/test/lock/seq-0000000001，依次类推，如果下图所示。

5.2 ZooKeeper节点的递增有序性，可以确保锁的公平

一个ZooKeeper分布式锁，首先需要创建一个父节点，尽量是持久节点(PERSISTENT类型)，然后每个要获得锁的线程，都在这个节点下创建个临时顺序节点。由于ZK节点，是按照创建的次序，依次递增的。

为了确保公平，可以简单的规定：编号最小的那个节点，表示获得了锁。所以，每个线程在尝试占用锁之前，首先判断自己是排号是不是当前最小，如果是，则获取锁。

5.3 ZooKeeper的节点监听机制，可以保障占有锁的传递有序而且高效

每个线程抢占锁之前，先尝试创建自己的ZNode。同样，释放锁的时候，就需要删除创建的ZNode。创建成功后，如果不是排号最小的节点，就处于等待通知的状态。
等谁的通知呢？不需要其他人，只需要等前一个ZNode的通知就可以了。前一个ZNode删除的时候，会触发ZNode事件，当前节点能监听到删除事件，就是轮到了自己占有锁的时候。第一个通知第二个、第二个通知第三个，击鼓传花似的依次向后。

ZooKeeper的节点监听机制，能够非常完美地实现这种击鼓传花似的信息传递。具体的方法是，每一个等通知的Znode节点，只需要监听(linsten)或者监视(watch)排号在自己前面那个，而且紧挨在自己前面的那个节点，就能收到其删除事件了。
只要上一个节点被删除了，就进行再一次判断，看看自己是不是序号最小的那个节点，如果是，自己就获得锁。

另外，ZooKeeper的内部优越的机制，能保证由于网络异常或者其他原因，集群中占用锁的客户端失联时，锁能够被有效释放。一旦占用Znode锁的客户端与ZooKeeper集群服务器失去联系，这个临时Znode也将自动删除。排在它后面的那个节点，也能收到删除事件，从而获得锁。正是由于这个原因，在创建取号节点的时候，尽量创建临时znode节点。

5.4 ZooKeeper的节点监听机制，能避免羊群效应

ZooKeeper这种首尾相接，后面监听前面的方式，可以避免羊群效应。所谓羊群效应就是一个节点挂掉，所有节点都去监听，然后做出反应，这样会给服务器带来巨大压力，所以有了临时顺序节点，当一个节点挂掉，只有它后面的那一个节点才做出反应。

创建的临时节点，客户端挂了，会话不存在了，节点也就被删除了，可以避免客户端因意外原因不释放锁。
超时只能依靠 ZooKeeper自身的sessionTimeout来删除节点。

5.5 Zookeeper与Redis分布式锁对比

分布式锁	优点	缺点
Zookeeper	1.有封装好的框架，容易实现 2.有等待锁的队列，大大提升抢锁效率	添加和删除节点性能较低
Redis	Set和Del指令性能较高	1.实现复杂，需要考虑超时，原子性，误删等情形 2.没有等待锁的队列，只能在客户端自旋来等待，效率低下

转载文章Zookeeper实现分布式锁Zookeeper入门看这篇就够了ZooKeeper概念详解，最全整理