6.zookeeper知识点

最新推荐文章于 2022-08-30 18:40:32 发布

竹子君@

最新推荐文章于 2022-08-30 18:40:32 发布

阅读量536

点赞数

文章标签： zookeeper

本文链接：https://blog.csdn.net/carzy01/article/details/109757362

版权

zookeeper

zookeeper的特点

分布式配置管理
统一命名服务
分布式锁
集群关系操作，检测节点的加入和离开
分布式消息队列
分布式锁
分布式通知协调等

顺序访问

Zookeeper工作原理

Zookeeper 的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和 leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态

zookeeper是如何保证事务的顺序一致性的？

zookeeper采用了递增的事务Id来标识，所有的proposal（提议）都在被提出的时候加上了zxid，zxid实际上是一个64位的数字，高32位是epoch（时期; 纪元; 世; 新时代）用来标识leader是否发生改变，如果有新的leader产生出来，epoch会自增，低32位用来递增计数。当新产生proposal的时候，会依据数据库的两阶段过程，首先会向其他的server发出事务执行请求，如果超过半数的机器都能执行并且能够成功，那么就会开始执行。

Zookeeper的文件系统

Zookeeper提供一个多层级的节点命名空间（节点称为znode）。与文件系统不同的是，这些节点都可以设置关联的数据，而文件系统中只有文件节点可以存放数据而目录节点不行。Zookeeper为了保证高吞吐和低延迟，在内存中维护了这个树状的目录结构，这种特性使得Zookeeper不能用于存放大量的数据，每个节点的存放数据上限为1M。

Zookeeper 下 Server工作状态

每个Server在工作过程中有三种状态：
LOOKING：当前Server不知道leader是谁，正在搜寻
LEADING：当前Server即为选举出来的leader
FOLLOWING：leader已经选举出来，当前Server与之同步

zookeeper的角色

zookeeper有三种角色：leader、follower、observer

一个 ZooKeeper 集群同一时刻只会有一个 Leader，其他都是 Follower 或 Observer

ZooKeeper 默认只有 Leader 和 Follower 两种角色，没有 Observer 角色。为了使用 Observer 模式，在任何想变成Observer的节点的配置文件中加入:peerType=observer 并在所有 server 的配置文件中，配置成 observer 模式的 server 的那行配置追加 :observer

ZooKeeper 的每个节点的配置文件(zoo.cfg)都是一样的，只有 myid 文件不一样。myid 的值必须是 zoo.cfg中server.{数值} 的{数值}部分。

1.ZooKeeper 集群的所有机器通过一个 Leader 选举过程来选定一台被称为『Leader』
的机器，Leader服务器为客户端提供读和写服务。

2.Follower 和 Observer 都能提供读服务，不能提供写服务。两者唯一的区别在于，
Observer机器不参与 Leader 选举过程，也不参与写操作的『过半写成功』策略，因

此 Observer 可以在不影响写性能的情况下提升集群的读性能。

为什么需要Observer？
　　• 为了支持更多的客户端，需要增加更多Server；
　　• Server增多，投票阶段延迟增大，影响性能；
　　• 权衡伸缩性和高吞吐率，引入Observer
　　• Observer不参与投票；
　　• Observers接受客户端的连接，并将写请求转发给leader节点；
　　• 加入更多Observer节点，提高伸缩性，同时不影响吞吐率

zookeeper的数据模型

层次化的目录结构，命名符合常规文件系统规范
　　» 每个节点在zookeeper中叫做znode,并且其有一个唯一的路径标识
　　» 节点Znode可以包含数据和子节点，但是EPHEMERAL类型的节点不能有子节点
　　» Znode中的数据可以有多个版本，比如某一个路径下存有多个数据版本，那么查询这个路径下的数据就需要带上版本
　　» 客户端应用可以在节点上设置监视器
　　» 节点不支持部分读写，而是一次性完整读写

zookeeper的结构其实就是一个树形结构，leader就相当于其中的根结点，其它节点就相当于
follow节点，每个节点都保留自己的内容。

 zookeeper的节点分两类：持久节点和临时节点
 - 持久节点：
         所谓持久节点是指一旦这个 树形结构上被创建了，除非主动进行对树节点的移除操
    作，否则这个 节点将一直保存在 ZooKeeper 上。

 - 临时节点：
         临时节点的生命周期跟客户端会话绑定，一旦客户端会话失效，那么这个客户端创
    建的所有临时节点都会被移除。

ZooKeeper & ZAB 协议 & Paxos 算法

ZAB 协议 & Paxos 算法

Paxos 算法可以说是 ZooKeeper 的灵魂了。但是，ZooKeeper 并没有完全采用 Paxos 算法，而是使用 ZAB 协议作为其保证数据一致性的核心算法。

另外，在 ZooKeeper 的官方文档中也指出，ZAB 协议并不像 Paxos 算法那样，是一种通用的分布式一致性算法，它是一种特别为 ZooKeeper 设计的崩溃可恢复的原子消息广播算法。

ZAB 协议介绍

ZAB（ZooKeeper Atomic Broadcast 原子广播）协议是为分布式协调服务 ZooKeeper 专门设计的一种支持崩溃恢复的原子广播协议。

在 ZooKeeper 中，主要依赖 ZAB 协议来实现分布式数据一致性，基于该协议，ZooKeeper 实现了一种主备模式的系统架构来保持集群中各个副本之间的数据一致性。

ZAB 协议两种基本的模式

ZAB 协议包括两种基本的模式，分别是崩溃恢复和消息广播。

当整个服务框架在启动过程中，或是当 Leader 服务器出现网络中断、崩溃退出与重启等异常情况时，ZAB 协议就会进入恢复模式并选举产生新的 Leader 服务器。

当选举产生了新的 Leader 服务器，同时集群中已经有过半的机器与该 Leader 服务器完成了状态同步之后，ZAB 协议就会退出恢复模式。

其中，所谓的状态同步是指数据同步，用来保证集群中存在过半的机器能够和 Leader 服务器的数据状态保持一致。

当集群中已经有过半的 Follower 服务器完成了和 Leader 服务器的状态同步，那么整个服务框架就可以进人消息广播模式了。

当一台同样遵守 ZAB 协议的服务器启动后加入到集群中时，如果此时集群中已经存在一个 Leader 服务器在负责进行消息广播。

那么新加入的服务器就会自觉地进人数据恢复模式：找到 Leader 所在的服务器，并与其进行数据同步，然后一起参与到消息广播流程中去。

ZooKeeper 设计成只允许唯一的一个 Leader 服务器来进行事务请求的处理。

Leader 服务器在接收到客户端的事务请求后，会生成对应的事务提案并发起一轮广播协议。

而如果集群中的其他机器接收到客户端的事务请求，那么这些非 Leader 服务器会首先将这个事务请求转发给 Leader 服务器。

zookeeper四种类型的znode

1、PERSISTENT-持久化目录节点
客户端与zookeeper断开连接后，该节点依旧存在
2、PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点
客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号
3、EPHEMERAL-临时目录节点
客户端与zookeeper断开连接后，该节点被删除
4、EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点
客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号