Zookeeper基础知识
2023-03-10 17:02:32 0 举报主要讲述Zookeeper的基础知识
作者其他创作
大纲/内容
什么是Zookeeper？有什么作用
是一种分布式协调服务
使用场景：
服务注册与发现 kess
配置中心 kconf
分布式锁
分布式协同
集群管理
工作原理
1、集群管理
zk以集群的方式进行运行，其中有一个节点是Leader，其余的节点是fllower，还有一些是observer。其中leader节点主要是单节点的写操作，fllower节点只要是同步数据以及投票，observer节点是为了应对写少读多的场景做的只读节点
2、数据储存
数据模型
ZNode 是一个树形结构 节点分为临时节点和永久节点，其中还有一种顺序节点 所以一共是4种 是否临时*是否有序 Znode底层的数据结构是concurrentHashMap
data 储存的数据信息
ACL 记录Znode的访问权限
stat 包含Znode的各种元数据 比如事务ID 版本号 时间戳 大小等等
child 当前节点的子节点的引用
数据格式
类似于文件系统 /a/b/c
数据提交
Leader负责将一个客户端事务请求转换成一个事务Proposal（提议），并将该Proposal分发给集群中所有的Follower节点（Leader会维持一个Follower列表）。之后Leader需要等待Follower的反馈，一旦超过半数的Follower进行了正确的反馈，Leader则会对所有Follower发起Commit消息，要求所有Follower将该Proposal进行提交（即写入Transaction Log）
基于永久节点的特性，可以用户做配置中心 -- kconf
图示
3、会话管理
zk使用基于心跳的会话来维持客户端与服务端之间的联系。每个服务端都有一个sessionId，如果服务端没有在固定的时间内收到客户端的PING，就断开连接。基于这个方式 我们可以用zk来做服务的注册与发现
session的过期时间是协商决定的。服务端保存了一个过期区间，如果客户端设置的过期时间在区间内，就使用客户端的过期时间，如果不在区间，还是以服务端的为准
4、事件通知
Watcher主要是通过Client、Server以及WatcherManager一起配合完成，主要是包括注册&触发两个阶段
注册：客户端通过SendThread线程向服务端发送请求，比如exist或者getData之类的
触发：当节点发生了变更，服务端则会在WatcherManager中挨个遍历watcher，然后把数据发送过去。当客户端的EventThread收到数据之后，则会执行相应的逻辑
销毁：watch是一次性的，如果服务端发送了一次watch，那么客户端则需要重新注册
用途
服务的发现与注册
配置中心
5、原子性操作
是指ZK更新数据的操作，要么全部成功 要么全部失败
ZAB协议
常识
ZAB协议是为Zookeeper专门设计的一种支持崩溃恢复的原子广播协议
ZK内部用ConcurrentHashMap<String /*Path*/, DataNode>来维持所有的Path，每个DataNode会挂一个子节点的Path列表。所以ZK对某个Path的插入和查询性能很高，并不需要遍历什么树，是直接对HashMap的操作。
ZAB协议主要包括两部分：崩溃恢复模型和原子广播协议
崩溃恢复模型
当Leader节点出现宕机、网络中断或者其他超过半数的fllower节点无法通信时，这时候fllower接口开始进行leader选举。当超过半数的节点同意，那么就选举出来了新的leader
在选举的时候，是可能出现数据丢失的。在前leader已经提交的数据，新的leader也会同步，在前leader已经提出，但是还没有提交的数据，则会丢弃
为什么zk的集群都是单数？
数据提交 & leader选举都是过半，所以单数能节约资源
当为双数的时候，可能会出现4比4的情况，称为脑裂，此时无法提供服务，所以也是为了防止脑裂
原子广播协议
请求的每一次提交都是Leader在写，写之前会为Proposal生成一个事务id(ZXID)，并且是单调递增的。
ZXID 的设计也很有特点，是一个全局有序的 64 位的数字，可以分为两个部分：
高 32 位是： epoch（纪元），代表着周期，每当选举产生一个新的 Leader 服务器时就会取出其本地日志中最大事务的 ZXID ，解析出 epoch（纪元）值操作加 1作为新的 epoch ，并将低 32 位置零。
低 32 位是： counter（计数器），它是一个简单的单调递增的计数器，针对客户端的每个事务请求都会进行加 1 操作；
高 32 位是： epoch（纪元），代表着周期，每当选举产生一个新的 Leader 服务器时就会取出其本地日志中最大事务的 ZXID ，解析出 epoch（纪元）值操作加 1作为新的 epoch ，并将低 32 位置零。
低 32 位是： counter（计数器），它是一个简单的单调递增的计数器，针对客户端的每个事务请求都会进行加 1 操作；
每一个Fllower都有一个专属的队列，所以leader需要把ZXID放到每一个队列去，当fllower消费之后也写事务日志到磁盘上，再向leader返回ask
当leader收到的ask大于一半的时候，就广播一个commit，同时完成对自身事务的提交
负载均衡
Zookeeper使用的是客户端负载均衡。当客户端连接到Zookeeper时，Zookeeper会返回一个可用的服务端节点列表。客户端会从列表中选择一个节点进行连接，如果节点无法响应，则会自动切换到下一个可用节点。这样可以将请求分散到不同的节点上，实现负载均衡。另外，Zookeeper还提供了一些监控工具来帮助管理员检测和管理节点的负载情况。
随机策略
轮循策略
最少连接策略 选择当前连接数最少的可用Zookeeper服务器作为客户端请求的目标。
哈希策略 根据客户端请求的内容计算一个哈希值，然后选择拥有该哈希值的Zookeeper服务器作为客户端请求的目标，从而实现请求的负载均衡。
权重策略 针对不同的Zookeeper服务器设置不同的权重值，根据权重值来选择目标服务器，从而实现请求的负载均衡。
分布式锁
实现原理：通过创建临时节点来表示是否获取到了锁
优势点：
创建临时有序节点(通过watch实现)可以避免羊群效应，也就是多个请求同时抢占
当客户端与zk断连的时候，临时节点自动删除
服务注册与发现架构设计
架构图
设计好处
1、实现了推拉结合
2、降低了ZK与服务的连接数
收藏
职业：后端
0 条评论
下一页
