深入浅出Zookeeper（一）：概览
原创
版本 | 日期 | 备注 |
|---|---|---|
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使用文件系统模型。主要基于两点考虑：
- 文件系统的树形结构便于表达数据之间的层次关系
- 文件系统的树形结构便于为不同的应用分配独立的命名空间（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的选举又是怎么进行的？
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。