zookeeper概述-白红宇

zookeeper概述

阅读量：3966 次

发布时间：2019-05-24

本文共 5455 字，大约阅读时间需要 18 分钟。

若图片转存失败可访问：

文章目录

作用

zookeeper是一个开源的分布式协调服务器框架，主要用来解决集群中应用系统的一致性和数据管理问题。

比如说在一个主机的上有多个进程同时对一个进程之间共享的资源或者说文件进行操作，那么这时就需要调度分配操作权限，资源或者文件是不能同时被多个进程操作的，当一个资源被使用的时候需要对其上锁以免被其他进程操作（类似多线程中的线程锁），而多个主机中的多个进程同时对共享资源进行操作又涉及到了网络问题，zookeeper就是用来解决这些问题的。

一致性问题：比如说两个共享资源是保持同步不的时候的不同进程之间的读写数据问题。

特点：

zookeeper是一个集群：zookeeper向外部提供一个文件系统，而用户不需要了解zookeeper内部结构。如图：

zookeeper本质上是一个分布式文件系统，适合存放一些小文件，zookeeper存储的其实是一个有一个的znode节点。

znode是有路径的，也就是znode的name

znode可以携带数据，也说明znode是有文件夹的特性

图中也可以看出来znode拥有子节点，也就是文件夹。

znode的这些特性让zookeeper可以对外提供一个类似文件系统的功能：

使用路径获取znode

获取znode携带的数据

修改znode携带的数据

删除znode

添加znode

架构

zookeeper是一个基于主从架构的高可用集群。

主从架构即为集群中有一个为主机其他为从属机子，且当client发送非事物性请求时如read可以交给fowller进行处理，当client发送事务性请求时如write如果client请求的是从机，那么从机只能转发给主机leader进行处理。

角色描述：

应用场景

数据发布与订阅系统（watch机制）：

在zookeeper集群中有一个叫做watch机制的东西，客户端在zookeeper注册之后，zookeeper中会有一个与Hadoop集群映射的文件也就是同步，当Hadoop中的源数据发生改变之后，zookeeper中的映射文件也会随之改变，这时watch机制就会向客户端发送通知，告诉客户端向Hadoop集群发出读取发生改变的源数据的请求。

分布式协调/通知：

主要包括三个部分：

心跳机制：

不同机器之间需要进行检测彼此是否在正常运行，zookeeper集群为每一台主机建立一个临时文件，机器需要在一定时间内向zookeeper集群发送心跳数据包用来维持这个临时文件，当在一定时间内zookeeper没有接收到这台机器的数据包，那么这个临时文件会立即消失，那么其他机器也会感知到这台机器已经宕机或者脱离了集群。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-c1Mc4WXC-1599990189814)(https://s1.ax1x.com/2020/09/12/wUXLvt.png)]

工作进度汇报

任务被分发给机器之后，机器需要实时地将工作进度汇报到，zookeeper为每个机器建立临时节点，各个机器将任务执行进度发送到临时文件夹中。中心系统能够实时获取任务进度。

系统调度

工作人员可以在控制台做一些操作，修改zookeeper上的数据进行任务地一些调度

分布式锁

排它锁又称为写锁或者独占锁，如果事物io对数据对象oi加上了排它锁那么在整个加锁期间只允许这个事件对数据对象进行操作，而其他任何事物都不能对数据进行任何类型的操作，直到事物释放了排它锁。

共享锁又称读锁，如果事务对数据对象加上共享锁，那么事务只能对数据对象进行读取操作，其他的事务也只能对数据对象加共享锁，直至数据对象上的所有共享锁都被释放。

分布式队列

有些时候多个团队需要共同完成同一个任务，需要一个类似单进程队列的组件，用来实现跨进程、跨主机、跨网络的数据共享和数据传递，就是分布式队列。

选举机制

服务器启动时的leader选举：

以三台服务器的集群为例，当至少有两台服务器启动时，互相可以通信，每个机器都试图找到leader，于是进入选举过程。

每个服务器发出一个投票，每个server都会将自己作为leader来进行投票，(myid,ZXID)

各个服务器接收投票，检查投票的有效性。

处理投票，针对每个投票服务器都会将别人的投票和自己的投票进行PK：优先检查ZXID，ZXID大的优先作为leader，若ZXID相同，按照myid较大的作为服务器。

统计投票：判断是否有过半的机器接收到相同的投票信息，若有则默认认为已经选出了leader。

改变服务器状态，确定leader之后，leader改为LEADING，follower改为FOLLOWING。

环境搭建

推荐使用北理的国内镜像源：

下载及解压：

进入/usr/local

curl -O http://mirror.bit.edu.cn/apache/zookeeper/zookeeper-3.4.14/zookeeper-3.4.14.tar.gz

tar zxf zookeeper-3.4.14.tar.gz

配置：

进入/zookeeper-3.4.14/conf

将zoo.cfg进行拷贝，并进行修改。

dataDir=/usr/local/zookeeper-3.4.14/zkdatas# the port at which the clients will connectclientPort=2181# the maximum number of client connections.# increase this if you need to handle more clients#maxClientCnxns=60## Be sure to read the maintenance section of the # administrator guide before turning on autopurge.## http://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_maintenance## The number of snapshots to retain in dataDirautopurge.snapRetainCount=3# Purge task interval in hours# Set to "0" to disable auto purge featureautopurge.purgeInterval=1server.1=master:2888:3888server.2=node1:2888:3888server.3=node2:2888:3888

文件夹中并没有zkdatas文件夹，这是用来存储机器的myid的。

master,node1,node2都是hadoop集群中设置的映射的ip。

以上这些操作都是在master机器上面进行的，下面我们只需要把解压好的文件夹拷贝到其他的机器上面并修改一下myid即可。

scp -r /usr/local/zookeeper-3.4.14 node1:/usr/local/

修改myid照着上面进行依次修改为2，3即可。

bin/zkServer.sh start

三台机器分别执行启动！

可以使用status来查看每台机器是否为leader：

bin/zkServer.sh status

zookeeper的数据模型

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BcWFTVRy-1599990189815)(https://s1.ax1x.com/2020/09/13/w0pDFx.png)]

zookeeper的数据模型和标准的文件系统大体相同，都是采用树形层次结构，zookeeper树中每个节点znode都可以有子节点，在前面提到过zookeeper中的znode本质上都是一个个文件，表示对源数据的映射。如下：

znode兼具文件和目录两种属性，用户可以对znode进行增删改查等操作，文件可以保存一些时间戳、元信息等，目录可以作为路径标识，

znode存储数据有大小限制，znode并没有被设计为存储大数据的，zno的存储单位通常以KB为单位。

znode需要通过路径引用，而且需要注意的是，引用的路径必须为绝对路径

每个znode由三个部分数据存储组成：stat：状态信息、描述版本、权限等。data：与znode关联的源数据。children：znode的子节点

znode的节点类型

znode有两种节点，分为临时节点和永久节点。

**临时节点：**节点生命周期依赖于会话，当会话结束的时候那么临时节点相应的被删除，也可以手动删除。注意临时节点不能够被创建子节点。

**永久节点：**节点生命周期不依赖于会话，只有在执行删除操作的时候才会被删除。

序列化：如果创建znode节点时指定节点序列化的特性，那么每创建一个znode节点后面都会增加一个不断增加的序列号如：“00000000001”，序列号越大，那么节点创建的时间就越晚。序列号对于此节点的父节点来说是唯一的。

四种类型：

PERSISTENT:永久节点

EPHEMERAL:临时节点

PERSISTENT_SEQUENTIAL:永久节点、序列化

EPHEMERAL_SEQUENTIAL: 临时节点、序列化

zookeeper的命令行操作：

常用命令：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-17lVDVRx-1599990189816)(https://s1.ax1x.com/2020/09/13/w0ejYQ.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1VkEO4BU-1599990189817)(https://s1.ax1x.com/2020/09/13/w0eQiQ.png)]

在使用zookeeper时谨记zookeeper集群是一直公用一套znode的。

znode的节点属性

对get中显示的各种参数的解释：

第一行就是znode存储的数据

**dataversion：**代表数据版本，每次对znode进行set操作的时候修改znode中存储的数据，dataversion都会+1（即使修改的数据与原数据相同）

**cversion：**子节点的版本号，每次当子节点有变化的时候，那么cverion+1。

**cZxid：**znode创建的事务id

**mZxid：**znode被修改的事务id，每次对znode修改都会更新mZxid。对于整个zookeeper来说每次的变化都会产生一个唯一的事务id，通过此id可以确定更新操作的先后顺序，先操作的id一定小于后操作的id。

**ctime：**节点创建的时间戳。

**mtime：**节点最新一次更新发生时的时间戳。

**ephemeralOwner:**如果节点为临时节点，那么该值表示的是与该节点绑定的session.id，如果不是临时节点，那么该项属性值为零。

zookeeper的watch机制

**发布和订阅：**客户端在zookeeper注册之后，zookeeper中会有一个与Hadoop集群映射的文件也就是同步，当Hadoop中的源数据发生改变之后，zookeeper中的映射文件也会随之改变，这时watch机制就会向客户端发送通知，告诉客户端向Hadoop集群发出读取发生改变的源数据的请求。

**监控集群中主机的存活状态：**比如在Hadoop集群中可以在zookeeper中为master机器创建临时节点，利用zookeeper的watch机制来处理节点宕机的情况，一旦master机器宕机，zookeeper心跳检测失败，那么watch机制立刻通知其他未宕机的机器来代替master机器的位置。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-C8S7KJfT-1599990189818)(https://s1.ax1x.com/2020/09/13/w03jtP.png)]

对znode设置一个watcher，当znode发生变化的时候不论是增删改创建子节点等watcher都会得到通知。

watcher的特点：