Zookeeper

参考链接：https://zookeeper.apache.org/doc/current/zookeeperOver.html

                  http://www.cnblogs.com/sunddenly/p/4033574.html

                           https://zhuanlan.zhihu.com/p/32238459

什么是Apache ZooKeeper？

Apache ZooKeeper是由集群（节点组）使用的一种服务，用于在自身之间协调，并通过稳健的同步技术维护共享数据。ZooKeeper本身是一个分布式应用程序，为写入分布式应用程序提供服务

 

ZooKeeper提供的常见服务如下 :

• 命名服务 - 按名称标识集群中的节点。它类似于DNS，但仅对于节点。

• 配置管理 - 加入节点的最近的和最新的系统配置信息。

• 集群管理 - 实时地在集群和节点状态中加入/离开节点。

• 选举算法 - 选举一个节点作为协调目的的leader。

• 锁定和同步服务 - 在修改数据的同时锁定数据。此机制可帮助你在连接其他分布式应用程序（如Apache HBase）时进行自动故障恢复。

• 高度可靠的数据注册表 - 即使在一个或几个节点关闭时也可以获得数据。

ZooKeeper的功能详解：                 https://zhuanlan.zhihu.com/p/32238459

                                         https://www.cnblogs.com/felixzh/p/5869212.html#undefined

ZooKeeper的架构

看看下面的图表。它描述了ZooKeeper的“客户端-服务器架构”。

 

组成ZooKeeper服务的服务器必须彼此了解。它们维护内存中的状态图像，以及持久性存储中的事务日志和快照。只要大多数服务器可用，ZooKeeper服务就可用。

客户端连接到单个ZooKeeper服务器。客户端维护TCP连接，通过该连接发送请求，获取响应，获取监视事件以及发送心跳。如果与服务器的TCP连接中断，则客户端将连接到其他服务器。 

 

遵循 C/S 模型。(这里C就是我们使用zk服务的机器，S自然就是提供ZK服务)。ZK可以提供单机服务，也可组成集群提供服务，还支持伪集群方式(一台物理机运行多个ZooKeeper实例）。客户端连接到一个单独的服务。客户端保持了一个TCP连接，通过这个TCP连接发送请求、获取响应、获取watch事件、和发送心跳。如果这个连接断了，会自动连接到其他不同的服务器。

层次命名空间

下图描述了用于内存表示的ZooKeeper文件系统的树结构。ZooKeeper节点称为 znode 。每个znode由一个名称标识，并用路径(/)序列分隔。

• 在图中，首先有一个由“/”分隔的znode。在根目录下，你有两个逻辑命名空间 config 和 workers 。

• config 命名空间用于集中式配置管理，workers 命名空间用于命名。

• 在 config 命名空间下，每个znode最多可存储1MB的数据。这与UNIX文件系统相类似，除了父znode也可以存储数据。这种结构的主要目的是存储同步数据并描述znode的元数据。此结构称为 ZooKeeper数据模型。

ZooKeeper数据模型中的每个znode都维护着一个 stat 结构。一个stat仅提供一个znode的元数据。它由版本号，操作控制列表(ACL)，时间戳和数据长度组成。

• 版本号 - 每个znode都有版本号，这意味着每当与znode相关联的数据发生变化时，其对应的版本号也会增加。当多个zookeeper客户端尝试在同一znode上执行操作时，版本号的使用就很重要。

• 操作控制列表(ACL) - ACL基本上是访问znode的认证机制。它管理所有znode读取和写入操作。

• 时间戳 - 时间戳表示创建和修改znode所经过的时间。它通常以毫秒为单位。ZooKeeper从“事务ID"(zxid)标识znode的每个更改。Zxid 是唯一的，并且为每个事务保留时间，以便你可以轻松地确定从一个请求到另一个请求所经过的时间。

• 数据长度 - 存储在znode中的数据总量是数据长度。你最多可以存储1MB的数据。

Zookeeper 工作流：

一旦ZooKeeper集合启动，它将等待客户端连接。客户端将连接到ZooKeeper集合中的一个节点。它可以是leader或follower节点。一旦客户端被连接，节点将向特定客户端分配会话ID并向该客户端发送确认。如果客户端没有收到确认，它将尝试连接ZooKeeper集合中的另一个节点。 一旦连接到节点，客户端将以有规律的间隔向节点发送心跳，以确保连接不会丢失。

 

• 如果客户端想要读取特定的znode，它将会向具有znode路径的节点发送读取请求，并且节点通过从其自己的数据库获取来返回所请求的znode。为此，在ZooKeeper集合中读取速度很快。

• 如果客户端想要将数据存储在ZooKeeper集合中，则会将znode路径和数据发送到服务器。连接的服务器将该请求转发给leader，然后leader将向所有的follower重新发出写入请求。如果只有大部分节点成功响应，而写入请求成功，则成功返回代码将被发送到客户端。 否则，写入请求失败。绝大多数节点被称为Quorum 。

ZooKeeper集合中的节点：半数以上原则，所以节点数最好是奇数（最大容错）

下图描述了ZooKeeper工作流：

 

组件	描述
写入（write）	写入过程由leader节点处理。leader将写入请求转发到所有znode，并等待znode的回复。如果一半的znode回复，则写入过程完成。
读取（read）	读取由特定连接的znode在内部执行，因此不需要与集群进行交互。
复制数据库（replicated database）	它用于在zookeeper中存储数据。每个znode都有自己的数据库，每个znode在一致性的帮助下每次都有相同的数据。
Leader	Leader是负责处理写入请求的Znode。
Follower	follower从客户端接收写入请求，并将它们转发到leader znode。
请求处理器（request processor）	只存在于leader节点。它管理来自follower节点的写入请求。
原子广播（atomic broadcasts）	负责广播从leader节点到follower节点的变化。

 

ZK的主要应用场景

• 配置管理（Configuration Management）
  配置的管理在分布式应用环境中很常见，例如同一个应用系统需要多台 Server 运行，但是它们运行的应用系统的某些配置项是相同的，如果要修改这些相同的配置项，那么就必须同时修改每台运行这个应用系统的 Server，这样非常麻烦而且容易出错。
  像这样的配置信息完全可以交给 Zookeeper 来管理，将配置信息保存在 Zookeeper 的某个目录节点中，然后将所有需要修改的应用机器监控配置信息的状态，一旦配置信息发生变化，每台应用机器就会收到 Zookeeper 的通知，然后从 Zookeeper 获取新的配置信息应用到系统中。
  下图是配置管理的结构图（引用）

• 集群管理（Group Membership)
  Zookeeper 能够很容易的实现集群管理的功能，如有多台 Server 组成一个服务集群，那么必须要一个“总管”知道当前集群中每台机器的服务状态，一旦有机器不能提供服务，集群中其它集群必须知道，从而做出调整重新分配服务策略。同样当增加集群的服务能力时，就会增加一台或多台 Server，同样也必须让“总管”知道。
  Zookeeper 不仅能够帮你维护当前的集群中机器的服务状态，而且能够帮你选出一个“总管”，让这个总管来管理集群，这就是 Zookeeper 的另一个功能 Leader Election。
  它们的实现方式都是在 Zookeeper 上创建一个 EPHEMERAL 类型的目录节点，然后每个 Server 在它们创建目录节点的父目录节点上调用getChildren(String path, boolean watch) 方法并设置 watch 为 true，由于是 EPHEMERAL目录节点，当创建它的 Server 死去，这个目录节点也随之被删除，所以 Children 将会变化，这时 getChildren上的 Watch 将会被调用，所以其它 Server 就知道已经有某台 Server 死去了。新增 Server 也是同样的原理。
  Zookeeper 如何实现 Leader Election，也就是选出一个 Master Server。和前面的一样每台 Server 创建一个 EPHEMERAL 目录节点，不同的是它还是一个 SEQUENTIAL 目录节点，所以它是个 EPHEMERAL_SEQUENTIAL 目录节点。之所以它是 EPHEMERAL_SEQUENTIAL 目录节点，是因为我们可以给每台 Server 编号，我们可以选择当前是最小编号的 Server 为 Master，假如这个最小编号的 Server 死去，由于是 EPHEMERAL 节点，死去的 Server 对应的节点也被删除，所以当前的节点列表中又出现一个最小编号的节点，我们就选择这个节点为当前 Master。这样就实现了动态选择 Master，避免了传统意义上单 Master 容易出现单点故障的问题。
  下图是集群管理的原理示意

• 共享锁（Locks）
  共享锁在同一个进程中很容易实现，但是在跨进程或者在不同 Server 之间就不好实现了。Zookeeper 却很容易实现这个功能，实现方式也是需要获得锁的 Server 创建一个 EPHEMERAL_SEQUENTIAL 目录节点，然后调用 getChildren方法获取当前的目录节点列表中最小的目录节点是不是就是自己创建的目录节点，如果正是自己创建的，那么它就获得了这个锁，如果不是那么它就调用 exists(String path, boolean watch) 方法并监控 Zookeeper 上目录节点列表的变化，一直到自己创建的节点是列表中最小编号的目录节点，从而获得锁，释放锁很简单，只要删除前面它自己所创建的目录节点就行了。
• 队列管理
  Zookeeper 可以处理两种类型的队列：
  1. 当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到达，这种是同步队列。
  2. 队列按照 FIFO 方式进行入队和出队操作，例如实现生产者和消费者模型。
  创建一个父目录 /synchronizing，每个成员都监控标志（Set Watch）位目录 /synchronizing/start 是否存在，然后每个成员都加入这个队列，加入队列的方式就是创建 /synchronizing/member_i 的临时目录节点，然后每个成员获取 /synchronizing 目录的所有目录节点，也就是 member_i。判断 i 的值是否已经是成员的个数，如果小于成员个数等待 /synchronizing/start 的出现，如果已经相等就创建 /synchronizing/start。
  FIFO 队列用 Zookeeper 实现思路如下：
  在特定的目录下创建 SEQUENTIAL 类型的子目录 /queue_i，这样就能保证所有成员加入队列时都是有编号的，出队列时通过 getChildren( ) 方法可以返回当前所有的队列中的元素，然后消费其中最小的一个，这样就能保证 FIFO。

 

单一视图保证

从上面的源码分析可知：当客户端正常连接集群中的一台服务器时，每次请求响应都会返回所连接的服务器上所处理的最新的事务id并进行记录。当客户端由于各种原因导致与服务器之间断连时，客户端将会以自己看到代表数据版本信息的zxid一起发送给服务端，请求建立连接。服务端在收到连接建立请求时，会进行判断：自己的数据版本没有客户端之前看到的数据版本新，服务端将会拒绝连接建立。从而保证客户端不会连接到数据版本比自己之前看到的旧的服务器上，因此不会请求到老版本的数据，从而保证了单一视图特性。

下面通过一个简单示例，来说明整个过程，如下图所示：

 

 

假设：集群中有三台服务器A/B/C，A为leader，其余两台为follower。

/**

* TIPS：ZooKeeper服务器角色说明

* Leader：领导者，是ZooKeeper集群的核心，负责集群各角色之间的协调和调度、事务请求的调度和处理，保证事务的顺序性以及数据一致性

* Follower：追随者，可独立处理非事务请求，转发事务请求给Leader，参与事务的投票以及Leader选举投票

* Observer：观察者，可独立处理非事务请求，转发事务请求给Leader，但是不参与各种投票，可提高整个集群的非事务请求处理能力

* 其中，Follower和Observer称之为Learner

*/

某一时刻，服务器A与C数据一致，zxid均为5，服务器B的zxid为4。当出现以下情况时，客户端与服务端的处理过程：

♦ 客户端client此时连接到服务器C，并且最后一个请求响应返回的zxid为5，client保存到lastZxid中

♦ 由于client与服务器C之间存在网络问题导致client与C之间断连。client开始重新与集群建立连接

♦ client随机到服务器B，开始与B建立连接

♦ 发送的连接建立请求中，携带lastZxid为5

♦ 服务器B接收到client的连接建立请求，判断自己的zxid与client传过来的lastZxid信息。发现客户端所看到的数据版本要比自己新（lastZxid > zxid），因此拒绝了client的建立连接的请求

♦ client与服务器B建立连接失败，开始新一轮尝试，向服务器A发送建立连接请求

♦ 服务器A同样去对比zxid以及客户端的lastZxid信息，发现版本一致，允许连接建立。至此，client与集群中的服务器A建立了新的连接。可以开始请求的发送与处理过程