版本 | 日期 | 备注 |
---|---|---|
1.0 | 2020.1.29 | 文章首发 |
1.1 | 2020.3.29 | 修改标题 |
最近趁着假期看起了Zookeeper,顺手把笔记理上来。
这个可以通过官网来看https://zookeeper.apache.org/。第一眼看过去,我们就知道它是一个分布式协同系统。并且提供了一些分布式系统中较常用的功能:如配置管理、DNS服务、分布式协同和组成员管理。
Zookeeper最早是起源于雅虎研究院的一个研究小组。在当时,研究人员发现,在雅虎内部很多软件系统都需要依赖一个系统来协同。但是这样的系统往往都存在单点问题。基于这个背景,雅虎的开发者开发了Zookeeper——一个通用无单点问题的分布式协同服务系统。
目前很多的开源分布式系统都用了Zookeeper,比如Hadoop、Kafka、HBase等。
Zookeeper使用文件系统模型。主要基于两点考虑:
Zookeeper的这种层次模型称作DataTree。DataTree的每个节点叫作ZNode。不同于文件系统,每个节点都有一个版本,从0开始计数。
虽然整体风格是UNIX的,但是在API操作的部分细节有所不同:
在Zookeeper中,ZNode大致分为4类:
相信有些同学已经想到了,根据现有的4种ZNode,调用者可以很方便的实现配置管理、DNS服务、分布式协同和组成员管理。
由于篇幅原因,在本篇中不会写具体的原理和细节。在这里仅仅抛出问题,在之后的文章中,我会一一解答。
我们经常会听到 “ZK适用于存储协同相关的关键数据,不适合用于大数量存储” 。那是为什么呢?由此,我们可以引出几个问题:
在本文中,我们已经知道Zookeeper是一个分布式协同系统。在一个大型的分布式系统中,必然会有大量的Client来连接Zookeeper。那么Zookeeper是如何管理这些Session的生命周期呢?
用过Zookeeper的同学都知道,Zookeeper提供了对ZNode Watch的API。那么它又是如何实现的呢?当其中一个ZkServer宕机时,Client重新连上时又会发生什么呢?
Zookeeper的一致性协议叫ZAB(Zookeeper Atomic Broadcast)。其原理更像一种2PC的变种,那么为什么不使用Paxos、Raft等一致性协议呢?相较前两者,使用ZAB协议带来的好处和坏处又是什么呢?
在Zookeper中,角色分为:Leader、Follower、Observer。每一个角色是如何响应Client的请求的?如何确认彼此的存活?Leader的选举又是怎么进行的?
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。