深入浅出Zookeeper（一）：概览

本文首发于泊浮目的简书:https://www.jianshu.com/u/204...

版本	日期	备注
1.0	2020.1.29	文章首发
1.1	2020.3.29	修改标题

最近趁着假期看起了Zookeeper，顺手把笔记理上来。

Zookeeper是什么

这个可以通过官网来看https://zookeeper.apache.org/。第一眼看过去，我们就知道它是一个分布式协同系统。并且提供了一些分布式系统中较常用的功能：如配置管理、DNS服务、分布式协同和组成员管理。

为什么会有Zookeeper

Zookeeper最早是起源于雅虎研究院的一个研究小组。在当时，研究人员发现，在雅虎内部很多软件系统都需要依赖一个系统来协同。但是这样的系统往往都存在单点问题。基于这个背景，雅虎的开发者开发了Zookeeper——一个通用无单点问题的分布式协同服务系统。

目前很多的开源分布式系统都用了Zookeeper，比如Hadoop、Kafka、HBase等。

数据模型

Zookeeper使用文件系统模型。主要基于两点考虑：

1. 文件系统的树形结构便于表达数据之间的层次关系
2. 文件系统的树形结构便于为不同的应用分配独立的命名空间（namespace）

Zookeeper的这种层次模型称作DataTree。DataTree的每个节点叫作ZNode。不同于文件系统，每个节点都有一个版本，从0开始计数。

虽然整体风格是UNIX的，但是在API操作的部分细节有所不同：

• ZNode的数据只支持全量写和读，不支持部分读写
• 所有的API都是Wait-Free——即正在做的API不会影响其他的API

ZNode分类

在Zookeeper中，ZNode大致分为4类：

• 持久性znode(persistent)：集群或client宕机则也不会丢失
• 临时性znode(ephemeral)：client宕机或client在指定timeout时间内没有给zookeeper集群发消息，节点则会消失
• 持久顺序性znode：除持久性，名字具备顺序性
• 临时顺序性znode：无持久性，名字具备顺序性

相信有些同学已经想到了，根据现有的4种ZNode，调用者可以很方便的实现配置管理、DNS服务、分布式协同和组成员管理。

原理与实现

由于篇幅原因，在本篇中不会写具体的原理和细节。在这里仅仅抛出问题，在之后的文章中，我会一一解答。

Zookeeper如何存储数据

我们经常会听到“ZK适用于存储协同相关的关键数据，不适合用于大数量存储” 。那是为什么呢？由此，我们可以引出几个问题：

• Zookeeper的数据存储是如何实现的？
• Zookeeper进行一次写操作的时候，会发生什么？
• Zookeeper进行一次读操作的时候，会发生什么？
• 相比数据库（以MySQL为例）来说，其读放大、写放大、空间放大的优劣
• 当一个Zookeeper新加入现有集群时，如何同步现集群中的数据？

Zookeeper的Session机制

在本文中，我们已经知道Zookeeper是一个分布式协同系统。在一个大型的分布式系统中，必然会有大量的Client来连接Zookeeper。那么Zookeeper是如何管理这些Session的生命周期呢？

Zookeeper的Watch机制

用过Zookeeper的同学都知道，Zookeeper提供了对ZNode Watch的API。那么它又是如何实现的呢？当其中一个ZkServer宕机时，Client重新连上时又会发生什么呢？

Zookeeper之ZAB协议

Zookeeper的一致性协议叫ZAB（Zookeeper Atomic Broadcast）。其原理更像一种2PC的变种，那么为什么不使用Paxos、Raft等一致性协议呢？相较前两者，使用ZAB协议带来的好处和坏处又是什么呢？

Zookeeper的角色

在Zookeper中，角色分为：Leader、Follower、Observer。每一个角色是如何响应Client的请求的？如何确认彼此的存活？Leader的选举又是怎么进行的？