zookeeper学习笔记

学习zookeeper,主要需要明白其中原理架构,一些开发框架稍作理解即可,代码还是越敲越熟练,这篇笔记着重介绍一下zookeeper的原理架构,开发框架推荐看一些客户端、服务端的框架,稍作了解即可。
想要简单深入的了解zookeeper,这里推荐去阅读一下paxos小岛 的故事,方便更加直观深入的理解zookeeper。

一、系统架构

1、zookeeper简介

Zookeeper是Google的Chubby一个开源的实现,是Hadoop的分布式协调服务
包含一个简单的原语集,分布式应用程序可以基于它实现

2、zookeeper服务架构——模型

在这里插入图片描述

3、zookeeper leader选举

1、每个服务器都发送一个报文,表示我是leader。报文当中包括两个字段:
ZXID:64位,前32位保存比较轮次信息;后32为保存消息ID,初始化时都是0,执行写操作时递增1。
MYID:每个server都有一个MYID,不同服务器的MYID不同。
首先比较ZXID,谁大选谁;ZXID一样的时候比较MYID,谁大选谁。
2、必须获取到半数以上的票数才能被选举为leader。如果集群当中的server启动时间不一致时,会影响选举结果。

4、关键性特性

在这里插入图片描述

提供集群模式的服务
原子性:准确的反馈成功或失败
一致性:每个server都有统一的数据视图
可用性:节点故障不影响使用
网络分区/脑裂:过半通过
3台机器 挂一台 2>3/2
4台机器 挂2台 2!>4/2
顺序性:队列FIFO
主从模型
一写多读

5、数据模型Znode

znode有两种类型,瞬时的(ephemeral)和持久的(persistent)
znode支持序列SEQUENTIAL:leader
短暂znode的客户端会话结束时,zookeeper会将该短暂znode删除,短暂znode不可以有子节点
持久znode不依赖于客户端会话,只有当客户端明确要删除该持久znode时才会被删除
znode的类型在创建时确定并且之后不能再修改
有序znode节点被分配唯一单调递增的整数。
比如:客户端创建有序znode,路径为/task/task-,则zookeeper为其分配序号1,并追加到znode节点:
/task/task-1。有序znode节点唯一,同时也可根据该序号查看znode创建顺序。
znode有四种形式的目录节点
PERSISTENT
EPHEMERAL
PERSISTENT_SEQUENTIAL
EPHEMERAL_SEQUENTIAL

稍加记忆,有些会在笔试或者面试中被问到

6、事件监听

基于通知(notification)的机制:

客户端向ZooKeeper注册需要接收通知的znode,
通过对znode设置监视点(watch)来接收通知。监视点是一个单次触发的
操作,意即监视点会触发一个通知。
为了接收多个通知,客户端必须在每次通知后设置一个新的监视
在这里插入图片描述

7、原子广播

Zookeeper的核心是原子广播,这个机制保证了各个server之间的同步。实现这个机制的协议叫做Zab协议。
Zab协议有两种模式:
恢复模式
广播模式
当服务启动或者在领导者崩溃后
Zab就进入了恢复模式,
当领导者被选举出来,且大多数server的完成了和leader的状态同步以后,恢复模式就结束了。
状态同步保证了leader和server具有相同的系统状态
在这里插入图片描述
(1)客户端(client)想follower发送请求,follower会将该请求发送给leader。(2)leader再将这个顺序更新,发送给follower,follower收到请求时,会持久化到硬盘。(3)当follower写到磁盘后,会向leader发送ack,当leader收到半数以上的ack时候,想全部的follower发送commit。(4)当follower收到commit后,就会将磁盘里的东西写进内存数据库,同时每条信息都会有一个递增的id。

8、zookeeper恢复模式

每个消息的id(zxid)是64位,前面32位称为epoch,后面32位称为counter。
(1)发现集群中被commit的proposal的最大的zxid,之后的leader不会commit比这zxid小的proposal,也就是说leader只能commit比这大的proposal。
(2)建立新的epoch,从而保证之前的leader不能再commit新的proposal(每选举出一个新的leader,epoch都会改变,且比之前的大,且保证一个leader的任期内,epoch不会被改变)。
(3)集群中大部分节点都commit过前一个leader commit过的消息,而新的leader是被大部分节点锁支持的(会选举出于前leader保持最为紧密的follower作为leader),所以被之前leader commit过的proposal不会丢失,至少被一个节点所保存。
(4)新的leader会与所有follower通信,从而保证大部分节点都拥有最新的数据。

二、zookeeper安装

1、选取奇数个节点
2、下载zookeeper
3、同步时间ntp
4、解压zookeeper到/opt下
5、配置conf文件
6、创建myid,编写服务器编号,启动
大致创建zookeeper集群的思路就在这里了,具体方法可以参考官网或者大佬的博客

三、zookeeper操作使用

1、节点中保存数据 create /ooxx “hello”
查看数据 get /ooxx
修改数据 set /ooxx
在ooxx下创建自己点 create /ooxx/ox “”
查看目录级别 ls /ooxx
2、临时节点操作
create -e /ooxxe “”
get /ooxxe
该数据可以在其他节点看到吗?可以
如果关掉创建临时节点的客户端,则在另一个session中查看,在超过过期时间之后该临时节点消失。
如果在过期时间内客户端恢复,则临时节点不会消失。
在这里插入图片描述
3、API操作
在这里插入图片描述在这里插入图片描述

### ZooKeeper 学习笔记 #### 1. 基本概念解析 ZooKeeper 是一个分布式的、开放源码的分布式应用程序协调服务,属于 Google Chubby 的一个开源实现[^5]。它提供了一套简单而强大的原语集,用于构建可靠的分布式系统。 - **一致性树结构**:ZooKeeper 使用层次化的命名空间来表示数据模型,类似于文件系统的目录路径。每个节点称为 znode,既可以保存少量的数据也可以作为其他 znodes 的父级容器。 - **临时节点与持久化节点**:创建时可以选择是否为临时节点;如果客户端会话结束,则该类型的znode会被自动删除。相反,对于持久化节点来说,在显式移除之前它们一直存在。 - **顺序节点**:当创建带有 SEQUENCE 标志的新节点时,Zookeeper 将为其分配一个全局唯一的递增编号并附加到名称后面形成完整的路径名。 #### 2. 最佳实践建议 为了确保高效稳定地运行 Zookeeper 集群和服务: - **合理规划集群规模**:通常情况下三台机器组成的奇数个成员构成的小型集群就足以满足大多数应用场景的需求,并能保证高可用性和容错能力。 - **配置参数优化**:调整诸如 `tickTime` (心跳间隔时间) 和 `initLimit/syncLimit` (初始化/同步限制次数)等关键属性以适应实际工作负载特点。 - **监控健康状态**:定期检查服务器日志以及通过命令行工具获取统计信息 (`mntr`) 或者四字指令(`ruok`, `stat`) 来评估整体性能表现和潜在问题所在。 ```bash echo stat | nc localhost 2181 ``` #### 3. 实际案例分析 假设有一个微服务体系架构下多个组件之间需要共享某些配置项或元数据的情况。此时就可以利用 Zookeeper 提供的服务发现功能让各个实例注册自己的地址端口等信息给中心节点,从而使得新加入的服务能够快速定位依赖对象的位置而不必硬编码这些细节于代码内部。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值