Zookeeper概述

---

Zookeeper简介

简介

1. zookeeper 是⼀个为分布式应⽤程序提供的⼀个分布式的服务配置管理系统。是 Google的 Chubby的⼀个开源实现，是 Hadoop 和 Hbase 的重要组件。主要⽤于解决分布式集群中应⽤系统的⼀致性问题。
2. 提供了基于类似 linux 系统的⽬录节点树⽅式的数据存储。
3. 可⽤于维护和监控存储的数据的状态的变化，通过监控这些数据状态的变化，从⽽达到基于数据的集群管理
4. 提供了⼀组原语 ( 机器指令 ) ，提供了 java 和 c 语⾔的接⼝

zookeeper功能

1. 存储数据
2. 动态监听

zookeeper构造机制

基于观察者模式设计的分布式服务管理框架

zookeeper的存储结构

目录树结构，类似linux文件系统

那些软件依赖zookeeper

1. HBase
2. Spark
3. Flink
4. Storm
5. Kafka
6. Dubbo

应用场景

1. 数据发布/订阅
2. 负载均衡
3. 命名服务
4. 分布式协调/通知
5. 集群管理
6. Master选举
7. 分布式锁
8. 分布式队列

官方网站

https://zookeeper.apache.org/

Zookeeper的特点

Zookeeper工作在集群中，对集群提供分布式协调服务，它提供的分布式协调服务具有如下的特点：

顺序一致性

从同一个客户端发起的事务请求，最终将会严格按照其发起顺序被应用到zookeeper中

原子性

所有事物请求的处理结果在整个集群中所有机器上的应用情况是一致的，即，要么整个集群中所有机器都成功应用了某一事务，要么都没有应用，一定不会出现集群中部分机器应用了改事务，另外一部分没有应用的情况。

单一视图

无论客户端连接的是哪个zookeeper服务器

可靠性

一旦服务端成功地应用了一个事务，并完成对客户端的响应，那么该事务所引起的服务端状态变更将会一直保留下来，除非有另一个事务又对其进行了改变

实时性

zookeeper并不是一种强一致性，只能保证顺序一致性和最终一致性，只能称为达到了伪实时性

ZooKeeper集群的角色

Leader

Zookeeper 集群工作的核心

事务请求 (写操作) 的唯一调度和处理者，保证集群事务处理的顺序性

集群内部各个服务器的调度者

对于 create, setData, delete 等有写操作的请求，则需要统一转发给leader 处理.leader 需要决定编号、执行操作，这个过程称为一个事务

Follower

处理客户端非事务(读操作)请求，转发事务请求给 Leader

参与集群Leader 选举投票

Observer

（对于访问量比较大的集群，可以新增观察者角色）

观察者角色，观察Zookeeper集群的最新状态变化并将这些状态同步过来，对于非事务请求可以进行独立处理，对于事务请求，则会转发给 Leader服务器进行处理

不会参与任何形式的投票只提供非事务服务，通常用于在不影响集群事务处理能力的前提下提升集群的非事务处理能力

Zookeeper的数据模型

zookeeper中可以保存数据，正是利用zookeeper可以保存数据这一特点，我们的集群通过在zookeeper里存取数据来进行消息的传递。

zookeeper中保存数据的结构非常类似于文件系统。都是右节点组成的树形结构。不同的是文件系统是由文件夹和文件来组成的树，而zookeeper中只有ZNODE来组成树。

每一个ZNODE里都可以存放一段数据，ZNODE下还可以挂载零个或多个子ZNODE节点，从而形成一个树形结构。

Zookeeper的数据模型采⽤的与 Unix ⽂件系统类似的层次化的树形结构。我们可以 将其理解为⼀个具有⾼可⽤特征的⽂件系统。这个⽂件系统中没有⽂件和⽬录，⽽是 统⼀使⽤" 节点 "(node) 的概念，称之为 znode 。 znode 既可以作为保存数据的容器 ( 如 同⽂件), 也可以作为保存其他 znode 的容器 ( 如同⽬录 ) 。所有的 znode 构成了⼀个层次 化的命名空间。

图中的每个节点称为一个Znode

每个 Znode 由3部分组成:

• stat：此为状态信息，描述该 Znode 的版本，权限等信息

• data：与该Znode 关联的数据

• children：该 Znode下的子节点

注：

1. Zookeeper 被设计⽤来实现协调服务（这类服务通常使⽤⼩数据⽂件 ) ，⽽不是⽤于 ⼤容量数据存储，因此⼀个znode 能存储的数据被限制在 1MB 以内，
2. 每个 znode 都可以通过其路径唯⼀标识。