Zookeeper面试整理

ZooKeeper是什么？

​ 分布式协调服务、为分布式服务提供一致性服、数据发布／订阅、分布式锁、master选举等服务。

ZK提供了什么？

​ 文件系统

​ 通知机制

ZK文件系统

​ 树状的目录（节点）结构，与文件系统不同，各个节点都存放数据，不能存放大数据，节点限制为1M

主从同步

Zab协议，两字模式原子广播模式和恢复模式

​ 原子广播保证了写数据 同步

​ 恢复模式保证了 启动和崩溃恢复情况下确定leader、进行数据同步

4种类型数据节点

• 持久节点：除非手动删除，否则一直存在
• 持久有序节点 ：持久节点 + 节点名后边会追加一个由父节点维护的自增整型数字****。
• 临时节点：基于一次客户端会话
• 临时有序节点 ：临时节点 + 节点名后边会追加一个由父节点维护的自增整型数字。

ZK Watcher机制

​ 工作机制：

（1）客户端注册 watcher

（2）服务端处理 watcher

（3）客户端回调 watcher

Watcher 特性总结：

​ （1）一次性

​ （2）客户端串行执行：客户端 Watcher 回调的过程是一个串行同步的过程。

​ （3）轻量：只通知发生事情，不通知具体内容

​ （4）异步通知，无法保证强一致性 通知

​ （5）注册 watcher监听3种方式： getData、exists、getChildren

​ （6）触发 watcher事件的3种方式 create、delete、setData

​ （7）当一个客户端连接到一个新的服务器上时，watch 将会被以任意会话事件触发

watch事件丢失情况：对于一个未创建的 znode的 exist watch，如果在客户端断开连接期间被创建了，并且随后在客户端连接上之前又删除了，这种情况下，这个 watch 事件可能会被丢失。

客户端注册Watcher监听

（1）调用 getData()/getChildren()/exist()三个 API，传入 Watcher 对象

（2）封装 Watcher 到 WatchRegistration

（3）封装成 Packet 对象，发送到服务端

（4）收到服务端响应后，将 Watcher 注册到 ZKWatcherManager 中进行管理

（5）请求返回，完成注册。

###服务端处理Watcher监听

（1）服务端接收 Watcher 并存储

​ 存储在WatcherManager 的 WatchTable 和 watch2Paths 中去。

（2）Watcher 触发

​ 以服务端接收到 setData() 事务请求触发 NodeDataChanged 事件为例：

​ a.封装 WatchedEvent：将通知状态（SyncConnected）、事件类型（NodeDataChanged）以及节点路径封装成一个 WatchedEvent 对象

​ b.查询 Watcher：从 WatchTable 中根据节点路径查找 Watcher

​ c.没找到；说明没有客户端在该数据节点上注册过 Watcher

​ c.找到；提取并从 WatchTable 和 Watch2Paths 中删除对应 Watcher（从这里可以看出 Watcher 在服务端是一次性的，触发一次就失效了）

（3）调用 process 方法来触发 Watcher

客户端回调 Watcher

​ 客户端 SendThread 线程接收事件通知，交由 EventThread 线程回调 Watcher。

​ 客户端的 Watcher 机制同样是一次性的，一旦被触发后，该 Watcher 就失效了

ACL权限控制机制

UGO（User/Group/Others）

目前在 Linux/Unix 文件系统中使用，也是使用最广泛的权限控制方式

ACL（Access Control List）访问控制列表

包括三个方面：

权限模式（Scheme）

（1）IP：从 IP 地址粒度进行权限控制

（2）Digest：最常用，用类似于 username:password 的权限标识来进行权限配置，便于区分不同应用来进行权限控制

（3）World：最开放的权限控制方式，是一种特殊的 digest 模式，只有一个权限标识“world:anyone”

（4）Super：超级用户

授权对象

授权对象指的是权限赋予的用户或一个指定实体，例如 IP 地址或是机器等。

权限 Permission

（1）CREATE：数据节点创建权限，允许授权对象在该 Znode 下创建子节点

（2）DELETE：子节点删除权限，允许授权对象删除该数据节点的子节点

（3）READ：数据节点的读取权限，允许授权对象访问该数据节点并读取其数据内容或子节点列表等

（4）WRITE：数据节点更新权限，允许授权对象对该数据节点进行更新操作

（5）ADMIN：数据节点管理权限，允许授权对象对该数据节点进行 ACL 相关设置操作

ZK服务器角色

Leader、Follower、Observer

ZK 服务器工作状态

looking观望状态、Following跟随状态、Leading领导状态、Observeing观察者状态

数据同步？？？

​ learner（follower和observer统称）

（1）直接差异化同步（DIFF 同步）

（2）先回滚再差异化同步（TRUNC+DIFF 同步）

（3）仅回滚同步（TRUNC 同步）

（4）全量同步（SNAP 同步）

1.由于崩溃选举是，使用lastProcessedZxid进行比较，所以新leader必然拥有最大的lastProcessedZxid，所以拥有最新的提交事务

2.提取其他follwer／observer服务的lastZxid

3.提议缓存队列committedLog中获取最小和最大zxid

​ 比较 lastZxid和[min,max]：

​ 在之间：DIFF,生成[lastZxid, max] proposal提案，commit

​ 提案lastZxid在[min,max]之间没找到（原先是leader，提案未提交就崩溃了），即这个zxid是leader所没有的，该follower需要回滚到leader上存在的。这时TRUNC + DIFF 同步。

​ 大于最大：TRUNC 同步 ，该follower需要回滚到leader上存在的max zxid

​ 小于最小：SNAP同步

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

​ 全局递增的事务 Id 来标识：zxid ，64位，高32位（全局时钟、一个leader统治的时期）， 低32事务请求计数。

为什么会有 Master主节点？

在分布式环境中，有些业务逻辑只需要集群中的某一台机器进行执行，其他的机器可以共享这个结果，这样可以大大减少重复计算，提高性能，于是就需要进行 leader 选举。

###ZK的watcher监听是一次性的？为什么是一次性的

因为在zk服务端数据变动频繁，而监听的客户端很多情况下，每次变动都要通知到所有的客户端，给网络和服务器造成很大压力。

而在在实际应用中，很多情况下，我们的客户端不需要知道服务端的每一次变动，我只要最新的数据即可。

​

ZK常见的命令

ls get set create delete

###ZAB 和 Paxos 算法的联系与区别？

相同点：

（1）两者都存在一个类似于 Leader 进程的角色，由其负责协调多个 Follower 进程的运行

（2）Leader 进程都会等待超过半数的 Follower 做出正确的反馈后，才会将一个提案进行提交

（3）ZAB 协议中，每个 Proposal 中都包含一个 epoch 值来代表当前的 Leader周期，Paxos 中名字为 Ballot

不同点：

ZAB 用来构建高可用的分布式数据主备系统（Zookeeper），Paxos 是用来构建分布式一致性状态机系统。