浅谈Zookeeper

最新推荐文章于 2024-03-28 21:33:10 发布

Ajaxtxdy

最新推荐文章于 2024-03-28 21:33:10 发布

阅读量346

点赞数

分类专栏：大数据文章标签： zookeeper

本文链接：https://blog.csdn.net/Ajaxtxdy/article/details/126256824

版权

简介
一、概述
1. Zookeeper是Apache提供的一套于用进行分布式管理和协调的框架

二、分布式的问题
1. 分布式容易存在死锁以及活锁问题
2. 分布式中，需要引入管理节点
3. 如果只有一个管理节点，容易存在单点故障，所以需要引入管理集群
4. 管理集群中需要选举出一个主节点
5. 管理节点之间需要进行信息的共享

三、安装
1. 单机模式：只用一个节点来安装，往往只能提供这个框架的部分功能
2. 伪分布式：只用一个节点来安装，但是模拟集群环境，能够提供框架的所有功能
3. 完全分布式：在集群中安装，提供这个框架的所有功能

四、特性
1. 过半性
2. 数据一致性 — 原子广播
3. 可靠性 — 崩溃恢复
4. 顺序性 — 队列、epochid
5. 实时性 — 可以对Zookeeper进行实时监控
6. 原子性 — 原子广播

细节
一、特点
1. Zookeeper本身是一个树状结构
2. 根节点是"/"
3. 将Zookeeper中每一个节点称之为znode节点
4. 每一个节点都要求携带数据
5. Zookeeper不支持相对路径
6. 将数据存储在磁盘以及内存中
7. 数据在磁盘上的存储位置由dataDir来决定
8. 理论上Zookeeper可以作为缓存机制使用，但是如果使用Zookeeper作为缓存机制，则会导致内存被大量占用，则致使Zookeeper的协调能力减弱
9. Zookeeper会对每一次的写操作（create/set/delete/rmr）分配一个全局递增的编号，这个编号称之为事务id - Zxid
10. 临时节点不能挂载子节点

二、命令

命令	解释
ls /	查看根节点的所有子节点
create /news ‘news server’	创建节点
delete /log	删除节点。要求这个节点没有子节点
rmr /news	递归删除
set /log ‘log servers’	更新数据
get /log	查看数据

三、节点信息

属性	解释
cZxid	创建事务id - create
ctime	创建时间
mZxid	修改事务id - set
mtime	修改时间
pZxid	子节点个数变化事务id
cversion	子节点个数变化次数
dataVersion	数据变化次数
aclVersion	权限变化次数
ephemeralOwner	用于标记当前节点是否是一个临时节点；如果是持久节点，此项为0；如果是临时节点，此项的值是sessionid
dataLength	数据的字节个数
numChildren	子节点个数

四、节点类型
在这里插入图片描述
选举机制
一、概述
1. 当Zookeeper在启动的时候，会先去恢复当前服务器上的最大事务id
2. 在选举开始的时候，每一个节点都会选举自己成为leader
3. 每一个Zookeeper服务器会将自己的选举信息发送给其他节点然后进行选举

二、细节
1. 选举信息：
a. 最大事务id
b. 选举编号 - myid
c. 逻辑时钟值 - 控制所有的节点处在同一轮选举上
2. 比较原则：
a. 先比较两个节点之间的最大事务id，谁大谁赢
b. 如果最大事务id一致，则比较myid，myid谁大谁赢
3. 如果一个节点比一半及以上的节点都大，则这个节点会成为leader - 过半性
4. 在Zookeeper中，只要一个集群中选举出来了leader，那么后续新添节点的事务id和myid无论是多少，都只能成为follower
5. 如果leader丢失，会自动重新选举出一个新的leader
6. 因为集群分裂导致子集群产生了leader致使整个集群中产生了多个leader，这个现象称之为脑裂
7. 如果存活的节点个数不足一半的时候，这个Zookeeper集群就不再选举也不再对外提供服务
8. Zookeeper集群的节点个数一般是奇数个
9. Zookeeper中会对每一次选举的leader分配一个全局递增的编号，编号称之为epochid，每一个节点在被选为leader之后，会将当前的epochid分发给每一个follower
10. 如果因为分裂而产生脑裂，恢复之后，Zookeeper会自动kill掉epochid小的那个节点
11. 集群节点状态变化：
a. voting/looking - 选举状态
b. follower - 追随者
c. leader - 领导者
d. observer - 观察者

ZAB协议
一、概述
1. ZAB(Zookeeper Atomic Broadcast) - Zookeeper原子广播协议，是针对Zookeeper专门设计的一套进行原子广播和崩溃恢复的协议
2. ZAB是基于2PC算法进行设计，利用PAXOS算法进行改进

二、原子广播
1. 保证数据一致性 - 访问任意一个节点，获取到的数据都是一样的
2. 基于2PC算法进行了改进，2PC - 2 Phase Commit - 二阶段提交
a. 将提交过程拆分为两个阶段：
i. 准备阶段：当协调者收到请求之后，将请求分发给每一个参与者，并且等待参与者的返回信息
ii. 提交阶段：如果协调者收到了参与者的返回信息，并且所有的参与者都返回了yes，那么协调者发布指令要求执行这个操作
iii. 中止阶段：如果协调者没有收到所有参与者的yes，那么协调者会认为这个操作不能执行，要求所有的参与者删除这个操作
b. 核心思想是"一票否决"

三、崩溃恢复
1. leader从集群中脱离之后，集群会自动选举出一个新的leader
2. 用于避免单点故障
3. 在Zookeeper中，每当产生一个新的leader，会自动分配一个全局递增的epochid，这个epochid同样会体现在Zxid上。在集群中，事务id实际上由64位二进制组成，其中高32位是epochid，低32位是真正的事务id
4. epochid能够有效的保证操作的提交顺序

观察者 - observer
一、概述
1. 特点：不投票不选举，但是会监听投票结果，然后根据投票结果执行操作
2. 观察者适合于节点数量较多或者网络情况不好的场景。在实际开发中，因为参与选举的节点的数量越多选举的效率会越低，所以实际过程中，会将90%的节点设置为observer
3. 因为observer不参与投票，所以observer不影响过半，即observer的存活与否都不会影响集群的服务

通过JAVA代码操作

package cn.tedu.zk;

import java.io.IOException;
import java.util.List;
import java.util.concurrent.CountDownLatch;

import org.apache.zookeeper.CreateMode;
import org.apache.zookeeper.KeeperException;
import org.apache.zookeeper.WatchedEvent;
import org.apache.zookeeper.Watcher;
import org.apache.zookeeper.ZooKeeper;
import org.apache.zookeeper.data.Stat;
import org.apache.zookeeper.Watcher.Event.KeeperState;
import org.apache