

首页  思维导图  详情



zookeeper知识体系

2022-06-14 23:00:40   0  举报





AI智能生成

zookeeper知识体系

元数据管理

zookeeper

模版推荐

作者其他创作

大纲/内容

zk概念说明

zk是什么

是一个分布式系统协调服务

Zookeeper 提供了一个类似于 Linux 文件系统的树形结构（可认为是轻量级的内存文件系统，但 只适合存少量信息，完全不适合存储大量文件或者大文件）

同时提供了对于每个节点的监控与 通知机制。

核心概念

znode节点

zk数据模型中的数据单元

类似于文件系统，以树形结构存储

包含的信息

path/唯一路径

childNode：子节点

stat：状态属性

type：节点类型

持久性节点

persistent持久节点

persistent_sequential持久有序节点

创建时会在路径上加上序号作为后缀

创建命令:create -s/path

persistent_with_ttl 待ttl的持久节点

persistent_sequential_with_ttl持久有序节点

临时节点（不能拥有子节点）

ephemeral 临时节点

ephemeral_sequential 临时有序节点

container容器节点

用于leader、lock等特殊用途，当容器节点不存在任何子节点时，容器将成为未来服务器在将来某个时刻删除的候选节点

节点对应的数值

版本号

每个znode都有版本号，随着每次数据变化自增

当多个client对node进行操作时保证了数据的一致性

节点权限（ACL）

保障数据安全的权限控制机制

包含的最大数据量是1mb

监听与通知（watcher）

定义

zk允许客户端向服务端的某个 Znode 注册一个 Watcher 监听

当服务端的一些指定事件触发了这个 Watcher， 服务端会向指定客户端发送一个事件通知来实现分布式的通知功能

然后客户端根据 Watcher 通知状态和事件类型做出 业务上的改变。

集群角色

Leader

zk集群同一时间只会有一个实际工作的 Leader， 它会发起并维护与各 Follwer及 Observer 间的心跳。

所有的写操作必须要通过 Leader 完成再由 Leader 将写操作广播给其它服务器

只要有超过半数节点（不包括 observeer 节点）写入成功，该写请求就会被提交

Follower

一个 zk集群可能同时存在多个 Follower，它会响应 Leader 的心跳

Follower 可直接处理并返回客户端的读请求，同时会将写请求转发给 Leader 处理

并且负责在 Leader 处理写请求时对请求进行投票

Observer

角色与 Follower 类似，但是无投票权

引入 Observer，Observer 不参与投票； Observers 接受客户端的连接，并将写请求转发给 leader 节点

加入更多 Observer 节点，提高伸缩性，同时不影响吞吐率

zk原子广播（zab）

Zab 协议模式

恢复模式

当服务启动或者在领导者崩溃后， Zab 就进入了恢复模式，当领导者被选举出来，且大多 数 server 的完成了和 leader 的状态同步以后，恢复模式就结束了

广播模式

一旦 leader 已经和多数的 follower 进行了状态同步后，他就可以开始广播消息了

ACL权限

CREATE

create子节点

READ

getChildren，getData

WRITE

setDate

DELETE

delete子节点

ADMIN

setACL

zk使用场景

服务发现/命名服务

分布式协调/通知

分布式（Master/leader）选举

子主题

数据发布/订阅

发布订阅模式

推(push)模式

拉（pull）模式

zk采用推拉结合模式

客户端向ZK注册自己关注的节点。 一旦该节点的数据发送了变化，那么zk就会向相应的客户端发送watcher事件通知。 客户端收到这个消息通知后，主动到服务端获取最新数据。

配置管理

分布式锁

zk核心机制流程

zk Watcher 机制

架构

子主题

主流程

客户端首先将Watcher注册到服务端，同时将Watcher对象保存到客户端的Watch管理器中

当ZooKeeper服务端监听的数据状态发生变化时，服务端会主动通知客户端

接着客户端的Watch管理器会触发相关Watcher来回调相应处理逻辑

Watcher 特性

一次性

客户端串行执行

轻量

客户端注册 Watcher流程

zk数据同步

说明

数据同步分类

DIFF：直接差异化同步

TRUNC+DIFF：先回滚再差异化同步

TRUNC：仅回滚同步

SNAP：全量同步

流程

follower将自己最大zxid发送给leader

leader根据follower的zxid来确定同步点

leader向follower发送proposal消息，并且紧跟着一条commit消息，标识该事物已经被提交

同步完成后follower状态变为update，提供服务

zk部署架构

部署模式分类

单机模式

伪集群模式

集群模式

核心概念

zk server状态

LOOKING：寻找Leader

LEADING：Leader状态，对应的节点为Leader。

FOLLOWING：Follower状态，对应的节点为Follower

OBSERVING：Observer状态，对应节点为Observer，该节点不参与Leader选举

ZXID（zookeeper transaction id）

每个改变Zookeeper状态的操作都会形成一个对应的zxid，并记录到transaction log中

这个值越大，表示更新越新

myid

服务器SID，一个数字,通过配置文件配置，唯一

SID

服务器的唯一标识

Leader的必要条件

Leader要具有最高的zxid

当集群的规模是n时，集群中大多数的机器（至少n/2+1）得到响应并follow选出的Leader。

集群选主

选主时机

启动时，集群服务器刚启动

运行时，Leader 崩溃

选主流程

每个服务器发送一个投票(SID,ZXID) 其中sid是自己的myid，初始阶段都将自己投为Leader

接收来自其他服务器的投票。

集群的每个服务器收到投票后，首先判断该投票的有效性， 如检查是否是本轮投票、是否来自LOOKING状态的服务器。

处理投票

针对每个投票都按以下规则与自己的投票PK， PK后依据情况是否更新投票，再发送给其他机器。

a.优先检查ZXID，ZXID较大者优先为Leader

b.如果ZXID相同，检查SID，SID较大者优先为Leader

统计投票

每次投票后，服务器统计所有投票，判断是否有过半的机器收到相同的投票， 如果某个投票达到一半的要求，则认为该投票提出者可以成为Leader。

改变服务器状态

一旦确定了Leader，每个服务器都更新自己的状态，Leader变更为Leading， Follower变更为Following 正常情况下一旦选出一个Leader则一直会保持， 除非Leader服务器宕掉，则再进行重新选举。

 Collect

Get Started

运营知识体系

 Collect

Get Started

马士兵知识体系

 Collect

Get Started

知识体系脑图

 Collect

Get Started

年度总结模板：阅读书单总结与知识体系构建





0 条评论

下一页