什么是ZooKe时代？把概念解释得最清楚的文章...

你真的了解ZooKe是什么吗？如果有人/面试官让你告诉他ZooKe时代是什么，你能回答到什么程度？

我使用了Construction eper作为Dubbo的注册中心。另外，在搭建solr集群时，我使用了ZooKe eper作为solr集群的管理工具。前几天，在总结项目经验的同时，我突然问自己：ZooKeeper到底是什么？想了想，想到了几句话：“①Zookeeper可以作为注册中心。②Zookeeper是Hadoop生态系统的一员；③搭建Zookeeper集群时，服务器数量最好是奇数” ” 显然我对 Zookeeper 的理解只是肤浅的。

所以，通过这篇文章，我希望能让您更详细地了解ZooKe。如果你还没有学过ZooKe经的话，那么这篇文章将成为你迈向ZooKe经之门的敲门砖。如果您已经接触过ZooKe经，那么本文将带您了解ZooKe经的一些基本概念。

最后，本文只是讲述ZooKe时代的一些概念，并不是关于ZooKe时代的使用和ZooKe时代集群的构建。 网上有文章介绍ZooKe的使用以及ZooKe的构建。 eper 集群。有需要的话你可以自己检查一下。

一什么是ZooKe经

ZooKe经的由来

以下内容摘自《从Paxos到Zookeeper 》第四章第一部分一段。建议您阅读以下内容：

Zookeeper 最初来自该研究所的研究组 Yahoo A。当时，研究人员发现雅虎内部的许多大型系统实际上依赖于类似的系统进行分布式协调，但这些系统经常存在分布式单点问题。因此，雅虎开发人员试图开发一个没有任何问题的通用分布式协调框架，以便开发人员可以专注于处理业务逻辑。

关于“ZooKeeper”这个项目的名称，其实还有一个有趣的故事。在项目初期，雅虎工程师想用动物来命名这个项目，因为很多内部项目都是以动物命名的（比如著名的Pig项目）。时任该研究所首席科学家拉古·拉马克里希南 (Raghu Ramakrishnan) 开玩笑说：“再这样下去，我们的房子就要变成动物园了！”这句话一出，大家都说叫他们zookeepers，因为每个发行版都是以动物命名的。将所有组件放在一起，Yahoo 的整个分布式系统就像一个大型动物园，而 Zookeeper 只是用来协调分布式环境 - 因此 Zookeeper 这个名字就诞生了。 。

1.1 ZooKe eper 概述

ZooKe eper 是一个开源的分布式协调服务。ZooKe eper 框架最初是建立在“Yahoo!”之上的。以简单而强大的方式提供对其应用程序的访问。后来，Apache Server 成为 Hadoop、HBase 和其他分布式框架使用的有组织服务的标准。例如，Apache HBase使用ZooKe eper来跟踪分布式数据的状态。 Kongzi eper的设计目标就是将这些复杂且容易出错的分布式一致性服务封装起来，形成高效可靠的原语集合，并为用户提供一组简单易用的接口。

原语： 操作系统或计算机网络的术语类别。它由多条指令组成，是用来完成某些功能的一个过程。它是不可分割的，即原语的执行必须是连续的，在执行过程中不能被中断。

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

Zookeeper 最常见的用例之一是充当服务生产者和服务消费者的注册中心。 服务生产者将自己提供的服务记录在Zookeeper中心。服务消费者在进行服务调用时，首先在Zookeeper中查找服务，从服务生产者那里获取详细信息，然后调用服务生产者那里的内容和数据。如下图所示，Zookeeper在Dubbo架构中扮演着注册中心的角色。 Dubbo

1.2 基于个人使用来说一下ZooKe eper

在我做过的项目中，我主要使用的是ZooKe eper作为Dubbo的注册中心（Dubbo官方推荐使用ZooKe eper注册中心）。另外，在搭建Solr集群时，我使用了ZooKe eper作为Solr集群的管理工具。目前，ZooKe eper主要提供以下功能： 1、集群管理：容错、负载均衡。 2.配置文件集中管理。 3. 访问集群。

个人认为，在使用ZooKe eper的时候最好使用集群版的ZooKe eper，而不是单机版。官网上的架构图描述了一个集群版本的Future eper。通常3台服务器可以组成一个ZooKe eper集群。

为什么使用奇数台服务器组成ZooKe eper集群比较好？

我们知道Zookeeper中的leader选举算法使用的是Zab协议。 Zab的核心思想是，当大多数服务器写入成功时，作业数据也写入成功。

①如果有3台服务器，则最多可以连接1台服务器。

② 如果有 4 台服务器，则最多可以连接 1 台服务器。

由于有3、4台服务器，最多允许一台服务器挂掉，所以它们的可靠性是一样的，所以只要选择奇数个ZooKe eper服务器即可。此处选择 3 个服务器。

2 关于ZooKe eper的一些重要概念

2.1重要概念总结

• ZooKe eper本身就是一个分布式程序（只要超过一半的节点存活，ZooKe eper就可以正常运行）。
• 为了保证高可用性，最好以集群的形式使用ZooKe eper。这样，只要集群中的大多数机器可用（容忍某些机器故障），ZooKe eper 本身仍然可用。
• ZooKe eper将数据存储在内存中，保证了高吞吐量和低延迟（但是内存限制了存储容量。这种限制也是为了让znode中存储的数据量保持相对较小的进一步原因）。
• ZooKe eper 提供高性能。这在读取多于写入的应用程序中提供了特别高的性能，因为写入可确保所有服务器间状态同步。 （‘读’多于‘写’是协同服务的典型场景。）
• ZooKe有临时节点的概念。只要创建临时节点的客户端会话保持活动状态，临时节点就存在。当会话结束时，临时节点将被删除。持久化节点是指一旦创建了ZNode，该ZNode就会一直保存在Zookeeper上，除非该ZNode被主动删除。
• ZooKe eper底层实际上只提供了两个功能：①管理（存储、读取）用户程序提交的数据； ②传输数据节点为用户程序提供监控服务。

下面对Session、Znode、Version、Watcher、ACL等概念的总结，都是在第4章第1节和第7章第8节中提到的，有兴趣的可以看一下！

2.2 会话

会话是指ZooKe eper服务器与客户端之间的会话。 在ZooKe中，客户端连接是指客户端和服务器之间的长TCP连接。客户端启动时，首先会与服务器建立TCP连接。客户端会话的生命周期也从第一次连接建立开始。 该连接允许客户端通过心跳检测与服务器保持有效的会话，也可以向Zookeeper服务器发送请求并接收响应，还可以通过该连接接收来自服务器的Watch事件通知。值 Session sessionTimeout 用于设置客户端会话的超时。当由于服务器压力过大、网络中断、客户端主动断开等各种原因导致客户端连接丢失时，可以重新连接集群，只要在sessionTimeout指定的时间内 无论在什么服务器上，之前创建的会话仍然有效。

在为客户端创建会话之前，服务器首先为每个客户端分配一个会话ID。因为sessionID是Zookeeper会话的重要标识，所以很多会话相关的控制都是基于这个sessionID的。因此，无论哪个服务器为客户端分配会话ID，它都必须是全局唯一的。

2.3 Znode

当我们谈论分布式时，我们通常所说的“节点”是指组成集群的每台机器。然而，在Zookeeper中，“节点”分为两类。第一类也是指组成集群的机器，我们称之为机器节点；第二类是指数据模型中的数据单元，我们称之为数据。节点一ZNode。

Zookeeper 将所有数据存储在内存中。数据模型是一棵树（Znode Tree）。由斜杠（/）分隔的路径是Znode，例如/foo/path1。每个服务器存储自己的数据内容以及一组属性信息。

在Zookeeper中，节点可以分为两类：永久节点和临时节点。所谓持久化节点，是指一旦创建了ZNode，该ZNode就会一直保存在Zookeeper上，除非该ZNode被主动删除。临时节点则不同。它的生命周期与客户端会话相关。一旦客户端会话过期，客户端创建的所有临时节点都将被删除。 此外，ZooKe eper还允许用户为每个节点添加一个特殊属性：SEQUENTIAL。一旦节点被标记了该属性，Zookeeper 在创建时会自动将其添加到该节点中。节点名称后会附加一个整数。该整数是由父节点维护的自动递增数字。

2.4版本

前面我们提到过，数据存储在Zookeeper的每个ZNode上。对应每个ZNode，Zookeeper维护了一个名为Stat的数据结构。 stat记录了这个ZNode的三个数据版本，分别是version（当前ZNode的版本）、cversion（当前ZNode子节点的版本）、cversion（当前ZNode的ACL版本）。

2.5 Watcher

Watcher（事件监听器）是Zookeeper中非常重要的功能。 Zookeeper允许用户在指定节点上注册多个Watcher，当某些特定事件被触发时，ZooKe eper服务器会将该事件通知给感兴趣的客户端。这种机制是Zookeeper实现分布式协调服务的一个重要特性。

2.6 ACL

Zookeeper使用ACL（AccessControlLists）策略进行权限检查，类似于UNIX文件系统的权限检查。 Zookeeper定义了以下5种权限。

特别需要注意的是，CREATE和DELETE这两个权限是子节点权限。

ZooKe eper的三大特点

• 顺序一致性：同一客户端发起的交易请求最终会严格按照顺序应用到ZooKe eper上。
• 原子性：所有事务请求的处理结果在集群中的所有机器上都是一致的。即整个集群中的所有机器都成功申请了一个事务，或者全部都不申请。
• 单个系统镜像：无论客户端连接到哪个ZooKe eper服务器，它看到的服务器数据模型都是相同的。
• 可靠性：应用更改请求后，更改的结果将保留，直到被下一次更改覆盖。

ZooKe eper 的四个设计目标

4.1 简单的数据模型

ZooKe eper 允许分布式进程通过共享的分层命名空间相互协调，类似于标准文件系统。命名空间由ZooKe中称为 eper - znode 的数据寄存器组成，类似于文件和目录。与典型的为存储而设计的文件系统不同，ZooKe eper 数据保存在内存中，这意味着 ZooKe eper 可以实现高吞吐量和低延迟。

4.2 可构建的集群

为了保证高可用性，最好以集群的形式部署ZooKe eper。这样，Zookeeper本身仍然可以使用，只要集群中的大多数机器可用（可以容忍某些机器故障）。 使用ZooKe eper时，客户端必须知道集群机器列表，并通过与集群中机器建立TCP连接来使用服务。客户端使用此TCP链路发送请求、获取结果、获取监听事件、发送心跳包。如果连接异常丢失，客户端可以连接到另一台机器。

ZooKe eper官方架构图：

上图中的每台服务器代表一台安装了Zookeeper服务的服务器。组成ZooKe eper服务的服务器在内存中维护当前的服务器状态，并且每个服务器之间保持通信。集群之间的数据一致性通过Zab（Zookeeper原子广播）协议来维护。

4.3 顺序访问

对于每个客户端更新请求，ZooKe eper 分配一个全局唯一的升序编号。这个数字反映了所有事务操作的顺序。应用程序可以使用ZooKe eper函数来实现这些更高级别的同步原语。 这个数字也称为时间戳 - zxid（Zookeeper 事务 ID）

4.4 高性能

ZooKe eper 提供高性能。这在读取多于写入的应用程序中提供了特别高的性能，因为写入可确保所有服务器间状态同步。 （‘读’多于‘写’是协调服务的典型场景。）

5 ZooKe eper 集群角色介绍

最典型的集群模式：Master/Slave 模式（主备模式） 。在这种模式下，Master服务器通常作为Master服务器提供写服务，而其他Slave服务器通过异步复制从Master服务器获取最新数据来提供读服务。不过，

并没有选择ZooKe时代传统的主奴概念，而是引入了三种角色：领导者、追随者和观察者。如下图

，ZooKe eper集群中的所有机器通过leader选举过程选出一台名为“Leader”的机器。领导者可以为客户提供写作和阅读服务。除了Leader、Follower和Observer只能提供读取服务之外。 Follower和Observer唯一的区别是Observer机器不参与Leader选举过程，也不参与写操作的“过半写成功”策略。因此，Observer机器可以在不影响写性能的情况下提高集群的读性能。

6 ZooKe eper & ZAB 协议 & Paxos 算法

6.1 ZAB 协议 & Paxos 算法

Paxos 算法应该是ZooKe eper 的灵魂。不过，ZooKe eper并没有完全采用Paxos算法，而是采用ZAB协议作为核心算法来保证数据的一致性。此外，ZooKe eper官方文档还指出，ZAB协议并不是像Paxos算法那样的通用分布式共识算法。它是专门为Zookeeper设计的一种崩溃可恢复的原子消息广播算法。

6.2 ZAB 协议简介

ZAB（ZooKe eper Atomic Broadcast）协议是专门为分布式协调而设计的原子广播协议。ZooKe eper 支持崩溃恢复。在ZooKe eper中，主要依靠ZAB协议来实现分布式数据的一致性。基于该协议，ZooKe eper实现了主备模式的系统架构，以维持集群内副本之间的数据一致性。

6.3 ZAB 协议的两种基本模式：崩溃恢复和消息广播

ZAB 协议包括崩溃恢复和消息广播 两种基本模式。当整个服务框架启动时，或者Leader服务器出现网络中断、崩溃、关机、重启等异常情况时，ZAB协议进入恢复模式，并选择新的Leader服务器。当新的Leader服务器被选择并且集群中超过一半的机器已经完成与Leader服务器的状态同步时，ZAB协议退出恢复模式。其中，所谓状态同步是指数据同步，用于保证集群中一半以上的机器能够保持与Leader服务器相同的数据状态。

当集群中超过一半的Follower服务器完成与Leader服务器的状态同步后，整个服务框架就可以进入消息广播模式。 当同样兼容 ZAB 协议的服务器启动并添加到集群中，并且集群中已有一台 Leader 服务器负责广播消息时，新添加的服务器会自觉地输入数据。 Recovery方式：找到Leader所在的服务器，与其同步数据，然后一起参与消息广播过程。正如上面介绍中提到的，ZooKe eper 的设计使得只有一台 Leader 服务器可以处理交易请求。 Leader服务器收到客户端的交易请求后，生成相应的交易提案并开始一轮广播协议；如果集群中的其他机器收到客户端的交易请求，这些非Leader服务器会首先转发该交易请求。到领导者服务器。

六大总结

看完这篇文章，你一定了解了①ZooKe的起源。 -> ②ZooKe到底是什么？ -> ③ ZooKe时代的一些重要概念 （Session、Znode、版本、Watcher、ACL）-> ④ ZooKe时代的特点。 -> ⑤ZooKe的设计目标。 ？ 这七点是ZooKe最懂的。