zookeeper--复习总结

本文深入探讨了Zookeeper,一种开源的分布式协调服务框架,详细讲解了其解决的分布式问题、特点、基础命令、节点类型、选举机制及配置信息,旨在帮助读者全面理解Zookeeper的工作原理。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

zookeeper的概念

zookeeper是开源的分布式的协调服务框架,是Apache Hadoop的自建,适用于绝大部分分布式集群的管理

分布式引发的问题

1.死锁:至少有一个线程占用了资源,但是不占用CPU
2.活锁:所有线程都没有把持资源,但是线程却在不断地调度占用CPU
3.需要引入一个管理节点
4.防止单一入口的单点问题,需要引入管理节点的集群
5.需要在管理阶段选举出一个主节点
6.需要确定一套选举算法
7.主从节点之间要保证数据的一致性

zookeeper的特点:

1.本身是一个树状结构–Znode树
2.每一个节点称之为znode节点
3.根节点是 /
4.zookeepe的所有操作都必须以根节点为基准进行计算 /
5.每一个znode节点都必须存储数据
6.任意一个持久节点都可以有子节点
7.任意一个节点的路径都是唯一的
8.Znode树是维系在内存中的–目的是为了快速查询
9.zookeeper不适合存储海量数据。原因有两点:1)维系在内存中,如果存储大量的数据会消耗内存 2)zookeeper并不是一个存储框架而是一个服务协调框架
10.zookeeper会为每一次事务(除了读取以外的所有操作都是事务)分配一个全局的事务id—Zxid

zookeeper的基础命令

1.create /node01 "hello zookeeper"在根节点下创建子节点node01并且为其赋值
2.set /node01 “hi” 将node01节点的数据改为hi
3.get /node01 获取node01的数据
4.ls / 查看根节点下所有的子节点
5.delete /node02 删除子节点,要求这个节点没有子节点
6.rmr /nodeo1 删除node01及其子节点
7.quit 退出客户端
8.create -e /node02 ''表示在根目录下创建临时节点/node02
9.create -s /node03 表示在根目录下创建持久不 顺序节点
10.create -e -s /node04 编排设计哦在根目录下创建临时顺序节点

zookeeper的节点类型

1.持久节点
2.临时节点:在客户端退出之后就自动删除
3.持久顺序节点
4.临时顺序节点

zookeeper的选举机制

zookeeper的选举是服从过半选举原则,分为两个阶段:
第一阶段:数据恢复阶段
从数据目录(dataDir)中恢复数据
第二阶段:选举阶段
1.所有的节点都会推荐自己当leader并发送自己的选举信息(最大事务id–pZxid,编号-myid,逻辑时钟值)
2.选举原则:先比较最大事务id,谁的事务id大谁就胜出;如果最大事务id一样吗,则比较myid,谁的myid大谁就胜出
3.选举出的leader的胜出要满足过半性:要比至少一半的节点大
4.如果在集群中加入一个节点,节点的事务id比leader的事务id大,子女的节点是否会成为leader?–不会。只要选定了一个leader,那么后续的节点的事务id和myid无论是多少,一律都是follower
6.如果超过一半的服务器宕机,那么此时的zookeeper将不再对外提供服务—过半性

节点状态

1.Looking–选举状态
2.follower–追随者
3.leader–领导者
4.observer–观察者

注意:zookeeper的投票是ZAB协议。ZAB是2PC协议的基础上来进行的延伸。
2PC:将节点分为了协调者和参与者。当一个请求来的时候,协调者是将请求分发给每一个参与者,如果所有的参与者决定执行这个请求,那么协调者就真正提交操作,由参与者执行,参与者在执行完成之后返回Ack表是执行成功。如果协调者将请求分发给每一个参与者之后,有一个或者多个参与者不同意执行或者没有返回消息,那么将这个操作回滚,不执行–具有一票否决权

在zookeeper中,接收一个请求之后,leader会将请求分发给每一个节点,由所有的节点投票确定是否执行这个请求–如果有超过一半的节点同意执行这个请求,leader才会决定执行这个操作。

过半性:

1.选举leader时要满足过半性
2.请求操作也要满足过半性
3.过半集群才能对外提供服务–目的:防止脑裂—集群中产生2个及以上的leader,所以将集群节点设置为奇数

观察者

观察者是只执行操作不参与宣教办和投票的节点
观察者不参与投票,所以就不影响集群的运行状态–适用于网络不稳定的情况
**具体设置方法:**找到要设置观察者的主机,标记zoo.cfg,添加peerType=observer,再在要设置的主句之后添加observer标记,例如:server.3=10.9.130.182:2888:3888:observer,然后重启这个节点

ZAB协议

基于2PC算法来进行了延展和延伸。ZAB是针对Zookeeper而专门设计的一套用于崩溃恢复和原子广播的协议。
崩溃恢复: 当zookeeper集群中的leader宕机之后,zookeeper集群不会出现单点问题,而是在满足过半性的条件下会快速地重新选举出一个新的leader,然后对外服务。在zookeeper的选举过程中,不会对外提供服务

原子广播
在这里插入图片描述
server.x=ip:port1:port2;
port1代表原子广播的端口号,也就意味着leader和follower的通信是通过这个端口进行传送
port2代表选举的端口号,选举信息是通过这个端口进行接收的
在这里插入图片描述
在这里插入图片描述
配置信息
在这里插入图片描述
zookeeper的特性总结:
1.数据一致性–从任意一个节点获取到数据时形同的
2.原子性
3.可靠性
4.顺序性-操作a先于b发生,那么在zookeeper中,a的事务一定是先于b
5.实时性-网络条件较好的情况下,可以对子节点进行监控
6.过半性-过半选举、过半服务、过半执行–集群中的节点个数一般是奇数个

Avro

avro是序列化和RPC的框架,Avro一开始是Apache Hadoop的子件之一,但是后来发现Avro不只可以用于hadoop而是可以用于多个场景下的序列化,所以单立出来形成一个新的组件。
序列化: 是将对象转化为二进制形式用于传输或者存储
java的原生序列化
1.java中的序列化无法做到结构的重用导致序列化之后的数据量偏大
2.java序列化是将对象转化为字节码,导致序列化之后的数据只能被java反序列化,其他语言想要解析java序列化产生的字节码实际比较困难的
Avro的特点:
1.提供了独立于语言的模式文件-schema
2.提供了丰富的数据类型:8种简单类型个以及6种复杂类型
3.支持RPC同信
4.对序列化文件进行了压缩
Avro的序列化:
在这里插入图片描述
Avro数据类型:
基本类型:null、int、long、boolean、String、bytes–对应json格式中的字符串、float、double
复杂数据类型:record、fixed、enums、arrays、maps、union
Avro创建对象
在这里插入图片描述
Avro序列化代码
在这里插入图片描述
Avro反序列化代码
在这里插入图片描述

RPC远程调用

在这里插入图片描述
在这里插入图片描述

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值