概述

  • Zookeeper是一个开源的分布式的，为分布式框架提供协调服务的Apache项目。
  • Zookeeper从设计模式角度来理解：是一个基于观察者模式设计的分布式服务管理框架，它负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变,Zookeeper 就将负责通知已经在Zookeeper上注册的那些观察者做出相应的反应。

Zookeeper=文件系统+通知机制

特点

① Zookeeper：一个领导者（Leader），多个跟随者（Follower）组成的集群。

② 集群中只要有半数以上节点存活，Zookeeper集群就能正常服务。所以Zookeeper适合安装奇数台服务器。

③ 全局数据一致：每个Server保存一份相同的数据副本，Client无论连接到哪个Server，数据都是一致的。

④ 更新请求顺序执行，来自同一个Client的更新请求按其发送顺序依次执行。

⑤ 数据更新原子性，一次数据更新要么成功，要么失败。

⑥ 实时性，在一定时间范围内(数据同步时间)，Client能读到最新数据。

数据结构

  • ZooKeeper 数据模型的结构与 Unix 文件系统很类似，整体上可以看作是一棵树
  • 每个节点称做一 ZNode。每一个 ZNode 默认能够存储1MB的数据
  • 每个ZNode都可以通过其路径唯一标识。

因此Zookeeper不适合存储海量的数据，而是存储简单的配置信息

应用场景

  • 统一命名服务
  • 统一配置管理
  • 统一集群配置
  • 服务器动态上下线
  • 软负载均衡

选举机制

首先要知道集群中节点的状态

  • leader：领导者，也就是 master 主节点，
  • follower：跟随者，也就是从节点 slave ，
  • observer：观察者，特殊的从节点，不参与主节点选举，只提供读操作
  • looking：是一个临时状态，在集群选举 master 过程中，所有的 follower 节点都会去竞选 master

集群中必须有主节点，否则无法正常工作。

以下三条是一些概念：

（1）Server id：服务器ID

（2）Zxid：事务ID(用于标识数据的可依靠程度)

（3）Epoch：逻辑时钟(leader迭代的版本)

初始状态

集群启动时，需要进行主节点的选举（假设这里有五台机器）：

每个节点都有自己携带的唯一id,

1.启动第一台机器1，发起选举，自己投票给自己，票数不过半，选举失败，服务器1保持looking状态。

2.启动第二台机器2，发起选举，1和2都先给自己投一票，1发现2 比自己的id大，所以把自己的票也投给服务器2，此时服务器2有2票，服务器1有0票，票数不过半，选举失败。

服务器1,2均保持looking 状态

3.启动第三台机器3，发起选举，1,2,3都先给自己投上一票，但是1和2发现服务器3的id比自己大，所以把自己的票都投给服务器3，次数服务器3票数过半，选举成功，服务器3当选leader

服务器1，2变为follower,服务器3变为leader.

此时已经选举成功了，后面两台机器的选举不会改变结果

4.启动第四台机器

发起一次选举，此时服务器1，2，3是folllower 状态，不会更改选票信息。此时：服务器3为3票，服务器4为1票。服务器4少数服从多数，更改选票信息为服务器3。

服务器4更改状态为follower

5.启动第五台机器

与服务器4一样投票给3，此时服务器3一共5票，服务器5为0票。

服务器5更改状态为follower

运行期间

服务器运行期间无法和Leader保持连接，此时会发起选举

而当一台机器进入Leader选举流程时，当前集群也可能会处于以下两种状态：

  • 集群中本来就已经存在一个Leader。 对于第一种已经存在Leader的情况，机器试图去选举Leader时，会被告知当前服务器的Leader信息，对于该机器来说，仅仅需要和Leader机器建立连接，并进行状态同步即可。
  • 集群中确实不存在Leader。
    • 假设ZooKeeper由5台服务器组成，
    • SID分别为1、2、3、4、5，
    • ZXID分别为8、8、8、7、7，
    • 并且此时SID为3的服务器是Leader。某一时刻， 3和5服务器出现故障，因此开始进行Leader选举。

选举Leader规则： ①EPOCH大的直接胜出 ②EPOCH相同，事务id大的胜出 ③事务id相同，服务器id大的胜出

节点

节点类型

  • 短暂（Ephemeral）：客户端和服务器端断开连接后，创建的节点自己删除

    • 临时目录节点：客户端与Zookeeper断开连接后，该节点被删除
    • 临时顺序编号目录节点： 客户端与 Zookeeper 断开连接后 ， 该 节点被删 除 ， 只是 Zookeeper给该节点名称进行顺序编号。

  • 持久（Persistent）：客户端和服务器端断开连接后，创建的节点不删除

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

说明：创建znode时设置顺序标识，znode名称后会附加一个值，顺序号是一个单调递增的计数器，由父节点维护 注意：在分布式系统中，顺序号可以被用于为所有的事件进行全局排序，这样客户端可以通过顺序号推断事件的顺序.

节点操作

  • 创建节点

    • 创建永久节点： create /sanguo/shuguo "liubei"
    • 创建临时节点： create -e /sanguo/wuguo "zhouyu"
    • 创建带序号节点： create -s /sanguo/weiguo/zhangliao "zhangliao"

  • 查看节点

    • ls 命令来查看当前 znode 的子节点
      • -w 监听子节点变化
      • -s 附加次级信息
    • 获得节点的值：get -s /sanguo

  • 修改节点

    • 修改节点的值：set /sanguo/weiguo "simayi"

  • 删除节点

    • 删除节点：delete /sanguo/jin
    • 递归删除节点：deleteall /sanguo/shuguo

监听器

客户端注册监听它关心的目录节点。

当目录节点发生变化（数据改变、节点删除、子目 录节点增加删除）时，ZooKeeper 会通知客户端。

监听机制保证 ZooKeeper 保存的任何的数据的任何改变都能快速的响应到监听了该节点的应用程序。

监听原理

1）首先要有一个main()线程

2）在main线程中创建Zookeeper客户端，这时就会创建两个线程，一个负责网络连接通信（connet），一个负责监听（listener）。

3）通过connect线程将注册的监听事件发送给Zookeeper。

4）在Zookeeper的注册监听器列表中将注册的监听事件添加到列表中。

5）Zookeeper监听到有数据或路径变化，就会将这个消息发送给listener线程。

6）listener线程内部调用了process()方法。

监听操作

  • 监听节点值变化

（1）注册监听/sanguo 节点数据变化get -w /sanguo

（2）修改/sanguo 节点的数据set /sanguo "xisi"

（3）观察主机收到数据变化的监听 

1
WATCHER:: WatchedEvent state:SyncConnected type:NodeDataChanged  path:/sanguo

注意：多次修改/sanguo的值，监听者不会再收到监听。因为注册 一次，只能监听一次。想再次监听，需要再次注册。

  • 路径监听

（1）在主机上注册监听/sanguo 节点的子节点变化 ls -w /sanguo

（2）在主机/sanguo 节点上创建子节点create /sanguo/jin "simayi"

（3）观察主机收到子节点变化的监听 

1
WATCHER:: WatchedEvent state:SyncConnected type:NodeChildrenChanged  path:/sanguo

注意：节点的路径变化，也是注册一次，生效一次。想多次生效，就需要多次注册。

分布式锁

在分布式场景中，采用传统的锁并不能解决跨进程并发的问题，所以需要引入一个分布式锁，来解决多个节点之间的访问控制。

唯一节点特性

我们可以基于唯一节点特性来实现分布式锁的操作，多个应用程序去抢占锁资源时，只需要在指定节点上创建一个 /Lock 节点，由于Zookeeper中节点的唯一性特性，使得只会有一个用户成功创建 /Lock 节点，剩下没有创建成功的用户表示竞争锁失败。

这种方法虽然能达到目的，但是会有一个问题，如下图所示，假设有非常多的节点需要等待获得锁，那么等待的方式自然是使用watcher机制来监听/lock节点的删除事件，一旦发现该节点被删除说明之前获得锁的节点已经释放了锁，那么此时剩下的B、C、D节点会同时收到删除事件从而去竞争锁，这个过程会产生惊群效应。

什么是“惊群效应”呢？简单来说就是如果存在许多的客户端在等待获取锁，当成功获取到锁的进程释放该节点后，所有处于等待状态的客户端都会被唤醒，这个时候zookeeper会在短时间内发送大量子节点变更事件给所有待获取锁的客户端，然后实际情况是只会有一个客户端获得锁。如果在集群规模比较大的情况下，会对zookeeper服务器的性能产生比较的影响。

有序节点

每个客户端都往指定的节点下注册一个临时有序节点，越早创建的节点，节点的顺序编号就越小，那么我们可以判断子节点中最小的节点设置为获得锁。如果自己的节点不是所有子节点中最小的，意味着还没有获得锁。这个的实现和前面单节点实现的差异性在于，每个节点只需要监听比自己小的节点，当比自己小的节点删除以后，客户端会收到watcher事件，此时再次判断自己的节点是不是所有子节点中最小的，如果是则获得锁，否则就不断重复这个过程，这样就不会导致惊群效应，因为每个客户端只需要监控一个节点。