Zookeeper_ms
2022-03-17 21:34:13 0 举报AI智能生成
zookeeper知识整理
作者其他创作
大纲/内容
概念
zookeeper是一款开源的分布式协调服务框架，为分布式环境提供了一致性服务的功能，常见应用场景有：发布订阅，主动通知，文件管理，集群管理，分布式锁等功能 zk在设计的时候满足了cp两要素，即一致性和分区容错性
zookeeper的设计理念
一致性
leader
数据树
zookeeper的设计目的
最终一致性：client不论连接到哪个Server，展示给它都是同一个视图，这是zookeeper最重要的性能
可靠性：具有简单、健壮、良好的性能，如果消息m被到一台服务器接受，那么它将被所有的服务器接受
实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。但由于网络延时等原因，Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口
原子性：更新只能成功或者失败，没有中间状态
顺序性：包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有Server上消息a都将在消息b前被发布；偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面
ZooKeeper数据模型
Zookeeper会维护一个具有层次关系的数据结构，它非常类似于一个标准的文件系统
数据结构的特点
每个子目录项如NameService都被称作为znode，这个znode是被它所在的路径唯一标识，如Server1这个znode的标识为/NameService/Server1
znode可以有子节点目录，并且每个znode可以存储数据，注意EPHEMERAL（临时的）类型的目录节点不能有子节点目录
znode是有版本的（version），每个znode中存储的数据可以有多个版本，也就是一个访问路径中可以存储多份数据，version号自动增加
znode的类型
Persistent 节点，一旦被创建，便不会意外丢失，即使服务器全部重启也依然存在。每个 Persist 节点即可包含数据，也可包含子节点
Ephemeral 节点，在创建它的客户端与服务器间的 Session 结束时自动被删除。服务器重启会导致 Session 结束，因此 Ephemeral 类型的 znode 此时也会自动删除
Non-sequence 节点，多个客户端同时创建同一 Non-sequence 节点时，只有一个可创建成功，其它匀失败。并且创建出的节点名称与创建时指定的节点名完全一样。
Sequence 节点，创建出的节点名在指定的名称之后带有10位10进制数的序号。多个客户端创建同一名称的节点时，都能创建成功，只是序号不同
znode可以被监控，包括这个目录节点中存储的数据的修改，子节点目录的变化等，一旦变化可以通知设置监控的客户端，这个是Zookeeper的核心特性，Zookeeper的很多功能都是基于这个特性实现的
ZXID：每次对Zookeeper的状态的改变都会产生一个zxid（ZooKeeper Transaction Id），zxid是全局有序的，如果zxid1小于zxid2，则zxid1在zxid2之前发生
ZooKeeper Session
如果Client因为Timeout和Zookeeper Server失去连接，client处在CONNECTING状态，会自动尝试再去连接Server，如果在session有效期内再次成功连接到某个Server，则回到CONNECTED状态。client不能宣称自己的session expired，session expired是由Zookeeper Server来决定的，client可以选择自己主动关闭session
分支主题
ZooKeeper的工作原理
三种角色
角色：leader,follower,observer
四种状态
状态：leading,following,observing,looking
Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议（ZooKeeper Atomic Broadcast protocol）。Zab协议有两种模式，它们分别是恢复模式（Recovery选主）和广播模式（Broadcast同步）
为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上了zxid
每个Server在工作过程中有4种状态
LOOKING：当前Server不知道leader是谁，正在搜寻。
LEADING：当前Server即为选举出来的leader。
FOLLOWING：leader已经选举出来，当前Server与之同步。
OBSERVING：observer的行为在大多数情况下与follower完全一致，但是他们不参加选举和投票，而仅仅接受(observing)选举和投票的结果。
ZooKeeper Watch
Zookeeper watch是一种监听通知机制。Zookeeper所有的读操作getData(), getChildren()和 exists()都可以设置监视(watch)，监视事件可以理解为一次性的触发器
（一次性触发）One-time trigger
（发送至客户端）Sent to the client
Consistency Guarantees
顺序一致性（Sequential Consistency）：从一个客户端来的更新请求会被顺序执行。
原子性（Atomicity）：更新要么成功要么失败，没有部分成功的情况。
可靠性（Reliability）：更新一旦有效，持续有效，直到被覆盖。
时间线（Timeliness）：保证在一定的时间内各个客户端看到的系统信息是一致的。
Leader Election
Zk的选举算法有两种：一种是基于basic paxos实现的，另外一种是基于fast paxos算法实现的。系统默认的选举算法为fast paxos
要使Leader获得多数Server的支持，则Server总数必须是奇数2n+1，且存活的Server的数目不得少于n+1
Leader工作流程
恢复数据；
维持与follower的心跳，接收follower请求并判断follower的请求消息类型；
Follower工作流程
主要功能
题目
ZooKeeper提供了什么
四种类型的znode
Zookeeper文件系统
Zookeeper通知机制
Zookeeper做了什么
zk的命名服务
zk的配置管理（文件系统、通知机制）
Zookeeper集群管理（文件系统、通知机制）
Zookeeper分布式锁（文件系统、通知机制）
获取分布式锁的流程
基于BaseDistributedLock实现了基于Zookeeper实现分布式锁的细节
12.Zookeeper队列管理（文件系统、通知机制）
同步队列，当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到达。
队列按照 FIFO 方式进行入队和出队操作。
13.Zookeeper数据复制
Zookeeper作为一个集群提供一致的数据服务，自然，它要在所有机器间做数据复制。数据复制的好处
14.Zookeeper工作原理
15.zookeeper是如何保证事务的顺序一致性的？
16.Zookeeper 下 Server工作状态
17.zookeeper是如何选取主leader的？
18.Zookeeper同步流程
19.分布式通知和协调
20.机器中为什么会有leader？
21.zk节点宕机如何处理？
22.zookeeper负载均衡和nginx负载均衡区别
23.zookeeper watch机制
一次性触发数据发生改变时，一个watcher event会被发送到client，但是client只会收到一次这样的信息
数据监视Zookeeper有数据监视和子数据监视getdata() and exists()设置数据监视，getchildren()设置了子节点监视
注册watcher getData、exists、getChildren
触发watcher create、delete、setData
Watch是轻量级的，其实就是本地JVM的Callback
内部指令整理
服务管理脚本
连接服务端指令
节点的增删改查
节点类型
默认创建的节点就是持久化类型
临时节点
持久化顺序节点
临时顺序节点
查看节点信息
节点属性
cZxid 当前数据结点创建时的事务ID
dataVersion：当前结点数据的发生更改的次数
ctime：当前数据结点创建时的时间
mZxid：当前数据结点最后一次更新时的事务ID
mtime：当前数据结点最后一次更新时的时间
配置
acl权限设置
scheme认证模型
permission权限位
acl 相关命令
acl 相关命令
zk集群的选举
zxid
zookeeper集群最少几台
投票整体思路
崩溃模式
zk的数据同步
如何保证主从节点的数据状态同步
ZAB协议
如何判断写请求提交成功
事务提交的一致性
广播模式
zk节点的数据变动通知特性
为什么不用mysql存储服务性能信息
收藏
0 条评论
下一页
