文章目录
1. 概述
Zookeeper是一个开源的分布式协调服务,由雅虎公司创建,是Google Chubby的开源实现,后来托管到Apache,于2010年11月正式成为Apache的顶级项目。 Zookeeper为分布式应用提供了高效且可靠的分布式协调服务,提供了如:数据发布与订阅、负载均衡、命名服务、分布式协调与通知、集群管理、Leader选举、分布式锁和分布式队列等功能。在解决分布式数据一致性方面,Zookeeper并没有直接采用Paxos算法,而是采用了一种被称为ZAB
的一致性协议。
1.1 Zookeeper 工作机制
Zookeeper 工作机制,如图所示:
Zookeeper 从设计模式角度来理解:是一个基于观察者模式设计的分布式服务管理框架,它负责存储和管理大家都关心的数据,然后接受观察者的注册和订阅。一旦这些数据的状态发生变化,Zookeeper负责通知订阅者做出相应的反应。
工作机制详解:
- 服务器节点启动时连接 Zookeeper,并注册信息(创建的都是临时节点)。
- 客户端获取到当前在线服务器列表,并注册监听。
- Zookeeper 监控到服务器节点上下线。
- Zookeeper 通知客户端服务器节点上下线事件。
- 客户端调用
process()
方法,重新获取新的服务器列表,并注册监听。
2. 特点
- Zookeeper:一个领导者(Leader),多个跟随者(Follower)和观察者(Observer)组成的集群。
- 集群中只要有半数以上的节点存活,Zookeeper 集群就能正常服。
- 最终数据一致:每个 Server 保存一份相同的数据副本,Client 无论连接到哪个 Server,数据都是一致的。
- 更新请求顺序进行,来自同一个 Client 的更新请求按照其发送顺序依次执行。
- 数据更新原子性,依次数据更新要么成功,要么失败。
- 实时性:Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息,或者服务器失效的信息。但由于网络延时等原因,Zookeeper不能保证两个客户端能同时得到刚更新的数据,如果需要最新数据,应该在读数据之前调用sync()接口。
3. 数据结构
Zookeeper 数据模型的结构与 Unix 文件系统很类似,整体上可以看作是一棵树,每个节点称作一个 ZNode。每个 ZNode 默认能够存储 1MB 的数据,每个 ZNode 可以通过其路径唯一标识。
在Zookeeper中,ZNode
可以分为持久节点和临时节点两类。持久节点是指只要这个 ZNode
被创建了,除非主动进行ZNode
的删除操作,否则这个ZNode
将一直保存在Zookeeper上。而临时节点就不一样了,它的生命周期和客户端会话绑定,一旦客户端会话失效,那么这个客户端创建的所有临时节点都会被移除。此外,Zookeeper还允许用户为每个节点添加一个特殊的属性:SEQUENTIAL
。一旦节点被标记上这个属性,那么这个节点创建的时候,Zookeeper会自动在其节点名后追加上一个整型数字。这个整型数字是由父节点维护的自增数字。
4. Zookeeper的基本概念
4.1 集群角色
在Zookeeper中,没有沿用传统的Master/Slave概念,而是引入了Leader、Follower和Observer三种角色。Zookeeper集群中的所有机器通过Leader选举过程选定一台机器为Leader。
4.1.1 Leader
Leader服务器是整个Zookeeper集群工作机制的核心,其主要作用有:
- 事务请求的唯一调度者,保证集群事务处理的顺序性。
- 集群内部各服务器的调度者。
- 处理事务请求和非事务请求。
4.1.2 Follower
Follower服务器是Zookeeper集群状态的跟随者,其主要工作如下:
- 处理客户端非事务请求,转发事务请求给Leader服务器。
- 参与事务请求Proposal(提议)的投票。
- 参与Leader选举投票。
4.1.3 Observer
Observer服务器充当了一个观察者的角色,观察Zookeeper集群的最新变化,并将这些状态同步过来。其主要工作如下:
-
处理客户端非事务请求,转发事务请求给Leader服务器。
-
不参与事务请求Proposal(提议)的投票。
-
不参与Leader选举投票。
4.2 会话(Session)
Session是指客户端会话。在Zookeeper中,一个客户端连接是指客户端和服务器之间的一个TCP长连接。Zookeeper对外的服务端口默认是2181.客户端启动的时候,首先会与服务器建立一个TCP连接。从第一次连接建立开始,客户端会话的生命周期也开始了。通过这个连接,客户端能够通过心跳检测与服务器保持有效的会话,也能够向Zookeeper服务器发送请求并接受响应,同时还能够通过该链接接收来自服务器的Watch事件通知。Session的sessionTimeout
值用来设置一个客户端会话超时时间。当由于服务器压力太大、网络故障或者客户端主动断开连接等各种原因导致客户端连接断开时,只要在sessionTimeout
规定的时间内能够重新连接上集群中任意一台服务器,那么之前创建的会话仍然有效。
4.3 数据节点(ZNode)
在Zookeeper中数据模型中的数据单元,我们称之为数据节点——ZNode
。Zookeeper将所有数据存储在内存中,数据模型是一棵树(ZNode Tree),由斜杆(/)进行分割的路径,就是一个ZNode
,例如/hbase/config
。每个ZNode上
都会保存自己的数据内容,同时还会保存一系列属性信息。
在Zookeeper中,ZNode
可以分为持久节点和临时节点两类。持久节点是指一定这个ZNode
被创建了,除非主动进行ZNode
的删除操作,否则这个ZNode
将一直保存在Zookeeper上。而临时节点就不一样了,它的生命周期和客户端会话绑定,一旦客户端会话失效,那么这个客户端创建的所有临时节点都会被移除。此外,Zookeeper还允许用户为每个节点添加一个特殊的属性:SEQUENTIAL
。一旦节点被标记上这个属性,那么这个节点创建的时候,Zookeeper会自动在其节点名后追加上一个整型数字。这个整型数字是由父节点维护的自增数字。
4.4 版本
前面我们已经提到,Zookeeper的每个ZNode
上都会存储数据,对应于每个ZNode
,Zookeeper都会为其维护一个叫做Stat
的数据结构,Stat
中记录这个ZNode
的三个数据版本,分别是version
(当前ZNode的版本号),cversion
(当前ZNode子节点的版本)和aversion
(当前ZNode的ACL版本号)。
4.5 Watcher
Watcher(事件监听器),是Zookeeper中的一个很重要的特性。Zookeeper允许用户在指定节点上注册一些Watcher,并且在一些特定事件触发的时候,Zookeeper服务端会将事件通知到感兴趣的客户端上。该机制是Zookeeper实现分布式协调服务的重要特性。
4.6 ACL
Zookeeper采用ACL(Access Control Lists)策略来进行权限控制,类似UNIX文件系统的权限控制。Zookeeper定义了如下5种权限:
- CREATE:创建子节点的权限。
- READ:获取节点数据和子节点列表的权限。
- WRTITE:更新节点数据的权限。
- DELETE:删除子节点的权限。
- ADMIN:设置节点ACL的权限。
5. 应用场景
提供的服务包括:统一命名服务、统一配置管理、统一集群管理、服务器节点动态上下线、软负载均衡等。