Zookeeper 启蒙

2018-12-14

关键词： Zookeeper入门介绍 、 Zookeeper是什么、Zookeeper架构解析、Zookeeper应用场景、Zookeeper有什么用

---

 

本篇文章系笔者依据当前所掌握的知识对 Zookeeper 做出的一个启蒙式介绍，不对文章的绝对、彻底正确性负责。

 

Zookeeper 对于大数据开发来讲实在是过重要了！ Zookeeper 是由雅虎研究院开发，现现在是 apache 基金会的一个顶级项目。本篇文章不会涉及太多专业知识，主要是想以聊天的方式向读者介绍一下笔者眼中的 Zookeeper 。

 

一、启蒙篇

1.一、Zookeeper 是什么？

 

官网上对于 Zookeeper 的一句话介绍是：一款支持高可用的分布式协调框架。这个介绍一看就显得它很高大上，不过对于不少初学者来讲，可能就会一头雾水了。不只官话很晦涩难懂，连市面上绝大多数教材在关于 Zookeeper 的介绍上都是狂甩那些让人懵圈的专业名词，什么配置维护啦，命名服务啦巴啦巴啦的。我就不喜欢这些一板一眼的东西。

 

说人话： Zookeeper 是一款用于在多台电脑之间同步消息用的。这话看起来就舒服多了吧！在分布式系统中，因为涉及到设备的物理隔离，各设备之间的消息传递、状态监控就变得极其重要且棘手。而 Zookeeper 就是为了解决这个问题而产生的。

 

那，Zookeeper 通常都在分布式系统中同步些什么消息呢？

a) 设备的状态信息

分布式系统中，咱们很是关心其它机器当前的上/下线等状态。一般每一台机器上线后都会在 Zookeeper 上注册本身的信息以供集群中其它机器能够知晓本身上线了，同时本身也能够经过 Zookeeper 得知当前还有哪些机器在线。

b) 关键信息同步

这个 “关键信息” 其实就说的很模糊了。其实本质上任何信息均可以被称之为是关键信息，均可以被保存在 Zookeeper 上，可是因为 Zookeeper 每一个节点的容量很是小，只有 1MB ，所以，只能将一些相当重要的信息保存在 Zookeeper 上。好比，HBase 会将相当重要的 meta 表的存储位置保存在 Zookeeper 上，任何有权限的客户端均可以经过 Zookeeper 获得存储地址后去访问 meta 信息。你看，即便 meta 表于 HBase 是相当重要的，但在 Zookeeper 上也仅仅是保存着其存储位置而非内容信息，由此，相信咱们也大概知晓该将什么信息放在 Zookeeper 上了吧。固然这里仅仅是举个小例子，其实只要你考虑到它每一个节点仅 1MB 的容量之后，你就能够根据你的业务需求在 Zookeeper 上存储任何数据。

 

 好，咱们来总结一下： Zookeeper 是一个在分布式系统之中分享消息用的开源软件框架。

zookeeper logo

 

1.二、Zookeeper 的应用场景

 

Zookeeper 通常在哪些场景下有应用呢？

 

这个问题真的很差回答。想象一下若是有人问你：“螺丝在哪些场景下有应用？”  你该如何回答？上至已经飞出太阳系的 “旅行者 1 号”，下及汽车手机甚至生物骨骼接驳，处处都能见到螺丝的应用场景。我猜，关于这个问题你很大多是沉吟一会后给出回答：“哪里须要螺丝，螺丝就在哪里有应用” 。是的， Zookeeper 也是！

 

咱们知道螺丝它的做用就是链接两个物理隔离物体，那么当咱们须要将某两个物理隔离的物体链接起来的时候，就会要用到螺丝了。而 Zookeeper 嘛，前面已经说到它是用于在多台电脑之间分享消息用的，因此当咱们的某个场景正好有这个需求时，那它就能有应用啦。好比，大名鼎鼎的 HBase 就是期望 Zookeeper 而活的。

 

一句话总结：Zookeeper 通常应用于有同步消息的分布式系统场景中。

 

这里额外探讨一个重要知识点：Zookeeper 的功能通常是如何来使用的？

咱们一直在说 Zookeeper 是一个给分布式应用提供消息同步服务的框架，那分布式应用平时都是如何来使用它提供的服务的呢？从设计模式的角度来看，Zookeeper 是一个基于 “观察者模式” 而设计的框架。应用通常会经过向 Zookeeper “注册监听” 的方式来实时监听咱们所感兴趣的数据。一般，一台机器在上线后，会主动链接配置好的 Zookeeper 集群，并向指定地址注册本身的信息或者请求消息监听，当监听的数据发生变化时，Zookeeper 就会主动向注册者发送回调消息。

 

1.三、Zookeeper 的架构与结构

 

 Zookeeper 是比较 “小巧” 的框架，它的内部只有两种角色： 1. Leader； 2. Follower 。同时它还能够划分为： 1. 服务端； 2. 客户端。 其架构图直接盗用官网的图片展现以下

zookeeper 架构

 什么是 “服务端” 与 “客户端” ？

在官网及其它教材上 Zookeeper 常常会被介绍为是一款为分布式应用提供协调服务的框架。因此它本质上也是提供服务用的。所以 “服务端” 是描述 Zookeeper 做为服务提供者的特性。通常咱们说 Zookeeper ，都是在说它的服务端功能。

 

至于客户端，就是开放给人使用的了，咱们通常会经过自带的客户端程序来查看当前服务端的状态及其存储的信息等。

 

关于 Leader 和 Follower

Leader 和 Follower 都是在服务端才有的角色划分。Zookeeper 在生产环境中都是以集群的状态来提供服务的。既然涉及到集群，那就必须得有一我的是 “说了算” 的。一个 Zookeeper 集群中，有且仅有一个 Leader 角色，其他的都是 Follower 。Zookeeper 自己是提供消息服务的，对于消息的基础操做莫过于 读和写 了。集群中全部成员都具备 读权限 。但只有 Leader 才具有 写权限 。

 

仅对 Leader 开放写权限的目的就是为了实现其 “数据一致性” 的。从上面架构图中能够看到，虽然客户端能够与任意一个 Follower 创建通讯，可是客户端能与 Follower 直接通讯的也仅有读取数据而已。若是客户端向某 Follower 发起 写请求 ，该 Follower 在接收到这个写请求后仍是会将写请求操做转发给 Leader ，让 Leader 来实现真正的数据写入操做，不过这一过程对客户端而言是透明的。正如上面架构图所示，Leader 和 Follower 之间也会有很紧密的交互联系，这些联系一部分是数据同步，另外一部分可能就是来自客户端的写请求了。值得一提的是，Zookeeper 会将数据完整地复制到全部机器上，这样才能实现客户端能够经过任意机器读取数据的功能。

 

关于 Zookeeper 的数据结构

Zookeeper 的数据结构和 Linux 文件系统结构是同样的。都是经过一个以 “ / ” 为根目录的目录树形结构。其结构图以下图所示

zk 目录树

 不过 Zookeeper 的目录树与 Linux 的文件系统的目录树还有一个不一样：Zookeeper 的目录名称自己是能够存储数据的。 以上图为例，在 Linux 文件系统中， app1 这个节点只能是做为 “目录” 存在，由于它内部还有子节点，app1 自己不能保存数据。而在 Zookeeper 中 app1 除了能有子节点之外，自己还能再保存数据。

 

在 Zookeeper 中，根节点 “ / ” 是默认存在的，而且在根目录内默认还有一个名称为 “zookeeper” 的子节点。每一个节点都被称为 “znode” ，它既能再扩展子节点，也能保存一段数据，默认每一个 znode 能存储 1MB 的数据。

 

Zookeeper 中的操做几乎都是发生在 znode 中的。znode 可分为两种类型：

1. 临时节点

又可分为普通节点和序列化节点。

2. 持久节点

又可分为普通节点和序列化节点。

关于临时节点和持久节点想必不用解释了吧。临时节点在会话结束后即会被销毁。序列化节点则是在你提供的节点名称后面自动加上一个用于标识当前节点在本路径下的序号，通常是用于防止因节点重名而创建失败的状况。不过序列化节点的用途可远不止于此，只是这里笔者为避免将知识点复杂化就不罗列了。

 

每一个 znode 节点还会有一些描述该节点的基本信息，以下图所示，下图中 cZxid ~ numChildren 即为节点的属性信息

节点属性信息

不过笔者认为，对于初次接触的同窗来讲，不须要去纠结这些属性信息是什么。只须要知道有这么个东西就差很少了。

  

二、 实战篇

原本想着在这里贴出一篇使用 Java 写的示例程序以演示一下 Zookeeper 在分布式应用中的使用方式的。但彷佛示例程序也过于简单，却又比较占篇幅，就算了。只在这里简单提一下吧，有兴趣的同窗本身随便摸索一下都能写出来的。

 

经过前面咱们知道临时节点的特性就是当会话断掉后即会被删除，并且节点还支持被各客户端注册状态改变的监听。利用这一特性就能很好地实现集群主机状态监控功能。所以，一般一台主机上线后，会当即在 Zookeeper 中注册一个本身并获取其它主机的节点信息。当某台主机宕机或断开链接后，其对应的节点信息就会被删除，并通知到其它节点主机中。主机之间须要同步什么信息，也是直接向事先约定的好路径写入数据便可。

 

---

 

2019-04-07 修改