zookeeper到底是干什么的？

zookeeper到底是干什么的？

我也是初学zk，整理下资料，希望能对你有帮助！

提起zk我们总会想到，zk可以被用作注册中心、构建zk集群时候节点最好为奇数……

可见我们对zk理解仅仅停在表面。那么zk到底是什么呢 ？

一、什么是zk？

了解zk之前我们首先要知道zk由来，zk能帮助我们做些什么事情？

1.1zk由来

举个例子，小王想找A团队安排点任务，所以小王找了A团队的leader小李，因为小李可以管理团队的成员，知道团队内的大大小小事情。小李协调安排了合适的人帮小王解决了需求。

那么小李，实际上承担了团队里面的协调作用，同样来说分布式系统也相当于一个团队，也需要这么一个协调者。如果小李不存在会出什么问题呢 ？

假设一个团队有三个员工：s1、s2、s3 (一个集群下三个服务)

这时候小王提出了几个问题：

1.s1员工换了一个工位（ip），防止其他员工找不到自己，怎么同步给其他员工呢？（每个服务都有一个配置文件，配置文件中信息动态变更，如何保证各节点数据一致性？）

2.来了一个新任务怎么分配给某个员工做？（保证一个任务只在一个service执行） 

3.员工s1辞职了，怎么通知其他员工，并把工作交接给别的员工？（某个service挂掉如何通知给其他service并接替它的任务？）

4.三个员工做任务时候都涉及到了一个公共文件，怎么保证这几个员工有序看这个文件并且保证这个文件在看的时候没有被另一个人修改？（保证节点当问共享资源的互斥性和安全性，类似多线程访问同一资源）

这时候就体现了小李承担着分布式协调的工作，我们都知道CAP理论，在选小李这样人才时候不由得思考到底是把CP还是AP放到第一位，选择CP我们就可以在同一时间同步员工信息相同，但是需要容忍一定的同步时间；AP就是需要容忍数据不一致问题，但是确保了员工们都正常给我们做任务。

其中zookeeper就是运用cp理论的分布式协调系统佼佼者。

如果把每个节点比喻成各种小动物，那zookeeper就是动物园管理员，这也是zookeeper名字由来

1.2简介

zk设计目标就是作为一个集群提供数据一致的协调服务，在整个及群众负责各个节点数据复制和同步。

zk是一个分布式协调服务，目的解决分布式一致性问题 。底层基于类似于文件系统的目录节点树的方式进行数据存储，同时维护和监控存储数据的状态变化，通过监控这些数据状态变化，从而达到基于数据的集群管理。

让我们看下官网的介绍 

1.3应用场景

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

许多开源应用都用到了zk，例如Kafka、Dubbo、Spark、Hbase等

上面zk提供的一些核心功能，后续会讲几个核心中的核心～

二、结构

核心：利用自己文件系统，同时这个文件系统可以监控目录变化 （文件系统+通知机制）

2.1 集群架构

 宏观结构：

zk集群中的server有3种角色：

leader：选举产生，负责进行投票的发起和决议，更新状态和数据。（不直接处理clieant请求，但是接受由其他follower和observer的请求）

follower：接受client请求并返回结果，在选举过程参与投票。

observer：接受client链接，写 *** 作会转给leader，不参与投票只同步leader状态。

为什么引入observer？

为了扩展系统，提供读取速度。不参与投票因此不影响投票耗时，也不影响集群选举。

运行模式：

应用使用 zk client库调用zk server，zk client会和集群中某一个节点建立 session， zk client 负责与zk server集群交互。每个client导入客户端库，便可和任何一个zk节点通信。

重连：client也可以主动关闭session，如果zk节点没有在timeout时间内收到session关联的客户端数据的话，zk节点也会关闭session。另外如果client库如果发现链接的zookeeper出错，会自动和其他的zk节点建立连接。

比如：应用1的客户端库和节点1建立session，一段时间后节点1down掉了，该客户端就自动和节点3建立了session链接

session会话

客户端与服务端建立会话后才能通信。客户端所有 *** 作均关联到一个会话上。

当session因为某原因种植时，这个会话期间创建的临时节点将会消失。

session中请求会FIFO顺序执行，，如果客户端拥有多个并发的session，多个会话中FIFO顺序未必能保持。

session有几种生命周期感兴趣的同学可以了解下。

zk集群有两种模式： 

• standalone 模式  -- 独立模式  （一个独立运行的节点，zk状态无法复制）
• quorum模式  --  仲裁模式 （一组zk节点-zk集合，可以进行状态的复制，同时为client提供）

举例一个kafka应用场景：

（此图引用：浅谈我们为什么需要zookeeper？_高世之智的博客-CSDN博客_为什么需要zookeeper） 

2.2 数据模型

下图是zk命名空间和标准文件系统的名称空间非常相似

zk会维护一个具有层次关系的数据结构，类似于一个分布式文件系统，zk中每个节点都是一个路径作为唯一标识，节点可以具有关联的数据+子节点，其叫做数据节点znode，znode可以存储1MB数据

如图展示了zk的两个节点：

znode特点：

• 每个子目录项如/hello都被叫做znode（路径唯一标识）
• znode有版本，也就是一个路径可以存储多份数据
• znode可以有子节点目录，也可以存储数据（EPHEMERAL类型不能有子节点目录）
• znode可以是临时节点，删除条件：1.客户端与服务器失去联系2.客户端和服务器采用长连接方式，通过心跳机制保持连接，连接状态称之为session，session失效时候znode会被删除
• znode目录名字可以自动编号，/test1存在就递推/test2
• znode会被监控（watch机制），比如存储数据修改，子节点目录变化，一旦变化就可以

 

 

2.3 服务节点类型