知识点整理：Zookeeper_zookeeper 收到超过一半follower的ack 确认

1. Zookeeper 是什么

Zookeeper 实际上就是 文件系统（树状目录结构） + 通知机制。

• Zookeeper 是一个基于 观察者模式 设计的分布式框架，它负责存储大家都关心的数据，然后接受观察者的注册。
• 一旦数据发生了变化，Zookeeper 就负责通知已经注册的那些观察者，从而实现集群中类似 Master/Slave 管理模式。

---

2. Zookeeper 特点

Zookeeper 是由一个领导者（leader）和多个跟随者（follower）组成的集群

• leader：负责投票的发起和决议，更新系统状态
• follower：负责接收客户请求并向客户端返回结果，在选举 leader 的过程中参与投票

Zokeeper 具有以下特点：

• 集群中只要有半数以上节点存活，Zookeeper 集群就能正常服务。
• 全局数据一致：每个 server 保存一份相同的数据副本，client 无论连接到哪个 server，数据都是一致的。
• 数据更新原子性：一次数据更新要么所有机器都成功，要么都失败。
• 实时性：在一定时间范围内，client 能读到最新数据。

---

3. ZAB协议

推荐阅读：Zab协议：一致性协议

3.1 ZAB 协议介绍

Zookeeper 是通过 ZAB 协议来保证分布式事务的最终一致性。Zab借鉴了 Paxos 算法，但又不像 Paxos 那样是一种通用的分布式一致性算法。它是特别为 Zookeeper 设计的支持崩溃恢复的原子广播协议。

Zookeeper 客户端会随机的链接到 zookeeper 集群中的一个节点。如果是读请求，就直接从当前节点中读取数据；如果是写请求，那么节点就会向 Leader 提交事务，Leader 接收到事务提交，会广播该事务，只要超过半数节点写入成功，该事务就会被提交。

Zab 协议包括两种基本的模式：崩溃恢复 和 消息广播

---

3.2 崩溃恢复

一旦 Leader 服务器出现崩溃或者由于网络原因导致 Leader 服务器失去了与过半 Follower 的联系，那么就会进入崩溃恢复模式。

崩溃恢复主要包括两部分：Leader选举 和 数据恢复

① 选举流程：

• 所有节点第一票先选举自己当leader，将投票信息广播出去；
• 从队列中接受投票信息；
• 按照规则判断是否需要更改投票信息，将更改后的投票信息再次广播出去；
• 判断是否有超过一半的投票选举同一个节点，如果是选举结束根据投票结果设置自己的服务状态，选举结束，否则继续进入投票流程。

② 数据恢复

当完成 leader 选举之后，leader 会先进行数据恢复（即数据同步）。leader 会确认事务日志中的所有的 proposal 是否已经被集群中过半的服务器 commit。

当所有 proposal 都已经确认没问题之后，leader 才会把 follower 加入到真正可用的 follower 列表中。也就是说，此时 leader 和 follower 的数据是保持一致的。

---

3.3 消息广播

一旦 leader 已经和 follower 进行了同步之后，它就可以开始广播消息了，即进入 消息广播 模式。

Zab协议的核心：定义了 事务请求 的处理方式

• Leader 负责将一个客户端事务请求，转换成一个事务 Proposal，并将该 Proposal 分发给集群中所有的 Follower ，也就是向所有 Follower 发送数据广播请求
• 分发之后 Leader 需要等待所有 Follower 的 Ack 请求。在Zab协议中，只要收到半数以上的 Follower 的 Ack 请求，那么 Leader 就会再次向所有的 Follower 发送 Commit 消息，要求 Follower 将该事务 proposal 进行提交。

---

4. 监听器原理

1. 首先有一个 main() 线程

2. 在 main 线程中创建 Zookeeper 客户端，会创建两个线程，connect 负责网络连接通信，listener 负责监听

3. 通过 connect 线程将注册的监听事件发送给 Zookeeper

4. 在 Zookeeper 的注册监听器列表中将注册的监听事件添加到列表中

5. Zookeeper 监听到有数据或路径变化，就会将这个消息发送给 listener 线程

6. listener 线程内部调用了process（）方法

---

5. 常用命令

• ls：查看子节点
• get：获取节点信息
• create：创建节点

---

6. Zookeeper 节点宕机如何处理？

zk 的机制是只要超过半数的节点正常，集群就能正常服务。只有当不到一半节点工作时，集群才失效。

• 如果是 follower 宕机，由于 zk 会进行数据同步，所以数据并不会丢失
• 如果是 leader 宕机，就需要进入 崩溃恢复 状态，重新选举出新的 leader ，并进行数据恢复

所以

3 个节点的 cluster 可以挂掉 1 个节点(leader 可以得到 2 票>1.5)

2 个节点的 cluster 就不能挂掉任何 1 个节点了(leader 可以得到 1 票<=1)

---

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

相同点：

• 都存在一个 leader 的角色，负责协调 follower 的运行
• leader 都会等待超过半数的 follower 的 ack 后，才会将一个事务提交
• ZAB 协议中，每个 proposal 都包含一个 epoch 表示当前 leader 周期，Paxos 中的名字是 Ballot

不同点：

ZAB 在 Paxos 的基础上额外添加了一个 数据同步 阶段。同步阶段中，新的 leader 会先确认事务日志中的所有的 proposal 是否已经被集群中过半的服务器 commit。

---

8. Zookeeper 实现分布式锁

锁服务可以分为两类：保持独占 和 控制时序

• 保持独占 ：我们将 zk 上的一个 znode 看做是一把锁，所有客户端都去 create 一个 /distribute_lock 节点，成功创建的那个客户端也就拥有了这把锁。用完之后删除掉 /distribute_lock 节点就释放出锁

• 控制时序：/distribute_lock 节点已经预先存在，所有客户端在它下面创建临时节点，按顺序进行编号。则编号最小的客户端获得锁，用完删除。