zookeeper笔记整理（二）

痛定思痛。 2023-02-25 10:18 10阅读 0赞

# Watcher 节点事件监听 #

zookeeper 提供了分布式数据的发布/订阅功能， zookeeper允许客户端向服务端注册一个 watcher 监听。

当服务端的一些指定事件（比如可以监听节点数据变更、节点删除、子节点状态变更等 ）触发了 watcher，那么服务端就会向客户端发送 一个事件通知。

值得注意的是， Watcher 通知是一次性的，即一旦触发一次通知后，该 Watcher 就失效了，因此如果要实现永久监听，可以通过循环注册来实现

通过这个事件机制，可以基于 zookeeper 实现分布式锁、集群管理等功能

# 实现分布式锁 #

利用 zookeeper 节点的特性来实现独占锁，就是同级节点的唯一性，多个进程往 zookeeper 的指定节点下创建一个相同名称的节点，只有一个能成功，另外一个是创建失败；

创建失败的节点全部通过 zookeeper 的 watcher 机制来监听 zookeeper 这个子节点的变化，一旦监听到子节点的删除事件，则再次触发所有进程去写锁；

## 存在的问题 ##

实现方式很简单，但是会产生“惊群效应”，简单来说就是如果存在许多的客户端在等待获取锁，当成功获取到锁的进程释放该节点后，所有处于等待状态的客户端都会被唤醒。

这个时候 zookeeper 在短时间内发送大量子节点变更事件给所有待获取锁的客户端，然后实际情况是只会有一个客户端获得锁。

如果在集群规模比较大的情况下，会对 zookeeper 服务器的性能产生比较的影响。

## 利用有序节点来实现分布式锁 ##

通过有序节点来实现分布式锁，每个客户端都往指定的节点下注册一个临时有序节点，越早创建的节点，节点的顺序编号就越小，那么我们可以判断子节点中最小的节点设置为获得锁。

每个节点只需要监听比自己小的节点，当比自己小的节点删除以后，客户端会收到 watcher 事件，此时再次判断自己的节点是不是所有子节点中最小的，如果是则获得锁，否则就不断重复这个过程，这样就不会导致惊群效应。

# Zookeeper 的 Java 访问框架 #

针对 zookeeper，比较常用的 Java 客户端有 zkclient、curator。由于 Curator 对于 zookeeper 的抽象层次比较高，简化了zookeeper 客户端的开发量。使得 curator 逐步被广泛应用。

# ACL 权限控制 #

为了保证 zookeeper 中的数据的安全性，避免误操作带来的影响。 Zookeeper 提供了一套 ACL 权限控制机制来保证数据的安全。

## (1)ZooKeeper 提供了如下几种验证模式： ##

1)IP  
通 过 ip 地 址 粒 度 来 进 行 权 限 控 制 ， 例 如 配 置\[ip:192.168.0.1\], 或者按照网段 ip:192.168.0.1/24 ;

2)digest  
digest模式是最常用的一种模式,形如"username:password"的方式。

3)World  
World模式其实是一种开放的模式,即对所以用户开放,设置格式是"world:anyone",事实上这种模式没什么效果,因为设置了也对所有人开放

4)Super  
Super模式是超级管理员模式,超级管理员可以对任何节点进行操作

## （2）权限类型 ##

指通过权限检查后可以被允许的操作 ， create /delete/read/write/admin  
Create 允许对子节点 Create 操作  
Read 允许对本节点 GetChildren 和 GetData 操作  
Write 允许对本节点 SetData 操作  
Delete 允许对子节点 Delete 操作  
Admin 允许对本节点 setAcl 操作

# Leader选举 #

实际使用ZooKeeper开发中，我们最常用的是[Apache Curator][]。 它由Netflix公司贡献给Apache。Curator 有两种选举 recipe（Leader Latch 和 Leader Election）

## Leader Latch ##

参与选举的所有节点，会创建一个顺序节点，其中最小的节点会设置为 master 节点, 没抢到 Leader 的节点都监听前一个节点的删除事件。

在前一个节点删除后进行重新抢主，当 master 节点手动调用 close（）方法或者 master节点挂了之后， 后续的子节点会抢占 master。其中 spark 使用的就是这种方法

## LeaderSelector ##

LeaderSelector 和 Leader Latch 最大的差别在于， leader可以释放领导权以后，还可以继续参与竞争

# Zookeeper 数据同步 #

见下方ZAB（Zookeeper Atomic Broadcast） 协议

# ZAB协议 #

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

ZooKeeper 中，主要依赖 ZAB 协议来实现分布式数据一致性 。

ZAB 协议包含两种基本模式，分别是 ：崩溃恢复 和 原子广播

## 恢复模式介绍 ##

当整个集群在启动时，或者当 leader 节点出现网络中断、崩溃等情况时， ZAB 协议就会进入恢复模式并选举产生新的 Leader，当 leader 服务器选举出来后，并且集群中有过半的机器和该 leader 节点完成数据同步后， ZAB 协议就会退出恢复模式。

在 Leader 节点正常工作时，启动一台新的服务器加入到集群，那这个服务器会直接进入恢复模式

## 广播模式介绍 ##

当集群中已经有过半的 Follower 节点完成了和 Leader 状态同步以后，那么整个集群就进入了消息广播模式。

leader 节点可以处理事务请求和非事务请求， follower 节点只能处理非事务请求，如果 follower 节点接收到非事务请求，会把这个请求转发给 Leader 服务器

## 消息广播原理 ##

消息广播的过程实际上是一个简化版本的二阶段提交过程

1.  leader 接收到消息请求后，将消息赋予一个全局唯一的64 位自增 id，叫： zxid，通过 zxid 的大小比较既可以实现因果有序这个特征
2.  leader 为每个 follower 准备了一个 FIFO 队列（通过 TCP协议来实现，以实现了全局有序这一个特点）将带有 zxid的消息作为一个提案（proposal）分发给所有的 follower
3.  当 follower 接收到 proposal，先把 proposal 写到磁盘，写入成功以后再向 leader 回复一个 ack
4.  当 leader 接收到合法数量（超过半数节点）的 ACK 后，leader 就会向这些 follower 发送 commit 命令，同时会在本地执行该消息
5.  当 follower 收到消息的 commit 命令以后，会提交该消息

和完整的 2pc 事务不一样的地方在于， zab 协议不能终止事务

## 崩溃恢复的实现原理 ##

一旦 Leader 节点崩溃，或者由于网络问题导致 Leader 服务器失去了过半的Follower 节点的联系那么就会进入到崩溃恢复模式。

### 崩溃恢复状态下 zab 协议需要做两件事： ###

\-1. 选举出新的 leader  
\-2. 数据同步

### 需要解决两个问题： ###

1.已经被处理的消息不能丢

这种是服务器leader已经发广播commit出去了，并向连接的客户端返回「成功」，然后崩溃或失联，为了最终能够在所有的服务器上执行，这种消息不能丢了。

2.被丢弃的消息不能再次出现

场景：当 leader 接收到消息请求生成 proposal 后挂了，其他 follower 并没有收到此 proposal，很久之后挂了的 leader 重新启动并注册成了 follower，他保留了被跳过消息的proposal 状态，与整个系统的状态是不一致的，需要将其删除。

### 实现办法： ###

1.保证新选举出来的 Leader 服务器拥所有机器最高编号（消息ZXID 最大）的事务Proposal，那么就可以保证这个新选举出来的 Leader 一定具有已经提交的提案。