第四章 ZooKeeper 与 Paxos

4.1 初识 ZooKeeper

4.1.1 ZooKeeper 的介绍

ZooKeeper 到底是什么？

《从Paxos到Zookeeper》这本书开篇就明确指出，ZooKeeper 是一个为分布式应用提供协调服务的开源项目。

我们可以把它理解成一个高可用的、高性能的、分布式的、具有强一致性保证的“文件系统”。但请注意，这个“文件系统”不是用来存储海量大文件的，而是专门用来存储和管理少量元数据（Metadata） 的，比如：配置信息、状态信息、命名服务等。

它的核心使命是帮助我们解决分布式应用中那些最棘手、最头疼的协调问题。具体来说，ZooKeeper 提供了以下核心功能：

1. 数据发布/订阅（配置管理）：将应用配置信息发布到 ZooKeeper 的一个或多个 ZNode 上，所有客户端监听这些 ZNode。一旦配置变更，客户端能立即收到通知并应用新配置。
2. 负载均衡：通过服务注册与发现机制实现。服务提供者将自身地址注册为临时节点，服务消费者获取可用的服务列表，并根据特定算法（如轮询、哈希）选择一个服务，实现动态负载均衡。
3. 命名服务（Naming Service）：为分布式系统中的资源（如服务、应用）提供一个全局唯一的、易于记忆的名称。通过 ZooKeeper 的树状结构，可以方便地为资源命名并存储其元信息。
4. 分布式通知/协调：利用 Watch 机制，一个节点可以通知其他节点某个事件的发生，实现系统间的协作。例如，心跳检测、任务执行进度的通知等。
5. 集群管理与服务发现：服务提供者启动时，将自己的地址注册到 ZooKeeper 的一个临时节点上。服务消费者通过监听这些节点，就能动态地发现可用的服务，并感知服务的上下线。
6. Master 选举：所有节点尝试创建一个唯一的临时节点，创建成功的那个就成为 Master。如果 Master 宕机，该临时节点会自动删除，其他节点可以再次尝试创建，从而选举出新的 Master。
7. 分布式锁：利用 ZooKeeper 的临时顺序节点特性，可以实现公平、可靠的分布式锁，用于控制对共享资源的互斥访问。
8. 分布式队列：利用顺序节点特性，可以在一个 ZNode 下创建一系列顺序节点，代表入队操作；通过消费这些子节点，可以实现先进先出（FIFO）的分布式队列。

ZooKeeper 的分布式一致性特征

为了实现可靠的协调服务，ZooKeeper 保证了以下几个重要的分布式一致性特征：

• 顺序一致性（Sequential Consistency）：来自同一个客户端的事务请求，将严格按照其发送顺序被应用到 ZooKeeper 中。对于所有客户端的更新请求，ZooKeeper 保证它们会按照 Leader 接收到的顺序被全局应用。
• 原子性（Atomicity）：所有事务请求的处理结果在整个集群中都是一致的，要么全部成功，要么全部失败。绝不会出现部分节点成功、部分节点失败的情况。
• 单一系统映像（Single System Image）：无论客户端连接到集群中的哪一个服务器，它所看到的服务端数据模型都是一致的。
• 可靠性（Reliability）：一旦一个更新操作被应用，这个更新的效果就会一直保留下来，直到被下一个更新操作覆盖。
• 实时性（Timeliness）：ZooKeeper 仅保证在一定时间段内，客户端最终一定能从服务端上读取到最新的数据状态，但不是强实时的。这也被称为“最终一致性”的一个变种。

ZooKeeper 的设计目标

ZooKeeper 在设计之初就确立了几个明确的目标，这使得它在功能和性能上表现出色：

1. 简单的数据结构：ZooKeeper 构建了一个层次化的、类似文件系统的树形数据结构（ZNode 树）。这种结构非常简单直观，易于理解和使用，并且适合存储和管理各类协调数据。
2. 可以构建集群：ZooKeeper 的一个核心设计就是以集群形式运行。一个集群通常由 3 到 5 台服务器组成，只要集群中超过半数的机器可用，整个 ZooKeeper 服务就是可用的，从而实现了高可用性。
3. 顺序访问：对于来自客户端的每一个更新请求，ZooKeeper 都会分配一个全局唯一的、严格递增的事务 ID（ZXID）。通过这个机制，ZooKeeper 保证了所有更新操作都具有全局的顺序性。
4. 高性能：由于 ZooKeeper 将全量数据存储在内存中，并直接服务于所有非事务请求（读请求），因此性能非常高。它尤其适合“读多写少”的应用场景。在写操作上，通过原子广播协议保证了高效的同步。

4.1.2 ZooKeeper 的基本概念

为了理解 ZooKeeper，必须掌握它的几个核心概念：

1. 集群角色（Cluster Roles）

   • ZooKeeper 集群中的服务器具有不同的角色，共同协作来保证服务的高可用和数据的一致性。主要有三种角色：
   • Leader（领导者）：负责处理所有改变系统状态的事务请求（写操作），并保证事务的顺序性。它将写请求通过原子广播协议同步给所有 Follower。一个 ZooKeeper 集群在同一时刻只有一个 Leader。
   • Follower（跟随者）：接收并处理客户端的非事务请求（读操作），并将事务请求转发给 Leader。它们参与 Leader 选举的投票，并从 Leader 接收状态更新。
   • Observer（观察者）：角色与 Follower 类似，也能处理读请求并将写请求转发给 Leader。但关键区别在于，Observer 不参与任何形式的投票（无论是 Leader 选举还是事务提交的 ACK），它们只是同步 Leader 的状态。引入 Observer 是为了在不影响写性能和选举效率的前提下，扩展集群的读性能。

2. 数据模型：ZNode

   • ZooKeeper 的数据都存储在一个层次化的树形结构中，非常类似于文件系统的目录树。
   • 树中的每一个节点被称为 ZNode。
   • 每个 ZNode 既可以像目录一样包含子节点，也可以像文件一样存储数据（通常是小数据，KB 级别）。
   • 每个 ZNode 都有一个与之关联的 Stat 结构，存储了该节点的状态信息，如版本号（version）、创建时间（ctime）、子节点数据版本号（cversion）等。

3. 节点类型：持久与临时，顺序与非顺序

   • 持久节点（Persistent）：一旦创建，除非被显式删除，否则会一直存在。
   • 临时节点（Ephemeral）：节点的生命周期与创建它的客户端会话（Session）绑定。一旦会话结束（客户端断开连接或宕机），该节点会被自动删除。这是实现服务发现和 Master 选举的关键。
   • 顺序节点（Sequential）：创建节点时，ZooKeeper 会在节点路径后自动追加一个单调递增的数字后缀。例如，创建 /lock/ 节点会变成 /lock/0000000001。这是实现分布式锁和序列号生成的关键。
   • 这几种类型可以组合，形成四种节点：持久节点、临时节点、持久顺序节点、临时顺序节点。

4. 会话（Session）

   • 客户端与 ZooKeeper 服务端之间的连接被称为一个会话。会话有超时时间。如果在超时时间内，服务端没有收到客户端的任何心跳（ping），则认为会话失效，与该会话关联的所有临时节点都会被删除。

5. Watch（监视器）

   • 这是 ZooKeeper 实现发布/订阅功能的核心机制。
   • 客户端可以对某个 ZNode 设置一个 Watch。当该 ZNode 发生变化（数据被修改、节点被删除、子节点列表变更）时，ZooKeeper 服务端会一次性地通知设置了 Watch 的客户端。
   • 特性：Watch 是一次性的（One-time Trigger）。如果想持续监听，客户端在收到通知后需要重新注册 Watch。

4.1.3 为什么选择 ZooKeeper

在众多分布式协调工具中，为什么 ZooKeeper 能脱颖而出，成为事实标准？

1. 简单的数据模型：树形结构直观易懂，API 简单（create, delete, exists, getData, setData, getChildren），学习成本低。
2. 丰富的节点类型：临时节点和顺序节点的组合，为解决各种复杂的分布式协调场景（服务发现、分布式锁等）提供了优雅且强大的原生支持。
3. 强大的 Watch 机制：为客户端提供了对数据变化的实时感知能力，是实现配置中心、服务发现等功能的基础。
4. 极高的可靠性与一致性：
   • 高可靠：ZooKeeper 以集群形式部署（通常是 3 或 5 个节点），只要超过半数的节点存活，整个服务就可用。
   • 强一致性：ZooKeeper 通过 ZAB 协议，保证了所有写操作的原子广播，确保了数据在节点间的顺序一致性。客户端从任何一个节点读取到的数据，要么是最新写入的，要么是比它更早的数据，绝不会读到“脏数据”。