一、什么是Zookeeper

Zookeeper 是一种分布式协调服务，它帮助分布式系统中的进程或服务之间进行协作。通过提供一套简单的原语和 API，Zookeeper 使得开发者可以更容易地实现复杂的协调任务，如：

• 配置管理：应用程序可以在 Zookeeper 中存储配置信息，并且可以在配置发生变化时得到通知。
• 命名服务：为分布式系统中的组件提供一个统一的名字空间，类似 DNS 之于互联网。
• 分布式同步：提供机制以确保多个节点之间的操作能够按照一定的顺序执行。
• 组成员管理：跟踪集群中成员的状态，检测成员的加入和离开。
• 领导选举：在一组服务器中选出一个领导者来协调某些活动。

Zookeeper 的核心概念包括：

• Znodes（节点）：类似于文件系统中的文件和目录，数据被组织成树状结构。
• Ephemeral nodes（临时节点）：这类节点在创建它们的客户端断开连接后会被自动删除。
• Watchers（监视器）：允许客户端等待特定事件的发生，例如节点数据的变化或子节点的增删。
• ACLs（访问控制列表）：用于控制哪些客户端可以对 znodes 执行什么类型的访问。

关于Zookeeper的简单介绍可以看我的另一篇blog：https://blog.csdn.net/Tracycoder/article/details/142792750

二、ZAB与Zookeeper的关系

ZAB（Zookeeper Atomic Broadcast）协议是 Zookeeper 的核心技术，它通过实现领导者选举、原子广播和事务日志同步，确保了分布式系统中数据的一致性和可靠性，并且能够在节点故障时维持服务的连续性和高可用性。ZAB 保证所有服务器按照全局一致的顺序处理更新操作，提供顺序一致性，同时支持一定的容错能力，使得 Zookeeper 能够有效地协调分布式应用程序中的各个组件。

虽然ZAB是在特定的应用场景下设计的（ZooKeeper），但它确实借鉴并实现了Paxos的核心思想——特别是关于如何通过多数派投票机制达成一致。因此，可以说ZAB是基于Paxos多数派思想的共识算法。

为什么Zookeeper不直接使用Paxos

Zookeeper 选择不直接使用 Paxos 协议，而是开发了自己的 ZAB协议，主要是因为 Paxos 虽然在理论上提供了强大的一致性保证，但在实际应用中实现和理解都非常复杂，尤其是在构建高效的分布式系统时。以下是 Zookeeper 不直接采用 Paxos 的一些主要原因：

• Paxos 的复杂性：Paxos 协议虽然解决了分布式共识问题，但其算法本身非常抽象且难以理解和实现。对于大多数开发者来说，正确地实现 Paxos 是一个挑战，这可能导致实现上的错误，影响系统的稳定性和可靠性。

• 性能考虑：Paxos 在处理某些类型的故障或网络分区时可能会导致性能下降。例如，在领导者选举过程中，Paxos 可能需要多次通信轮次才能达成一致，这在高负载或网络延迟较高的情况下会显著降低性能。

• 特定需求：Zookeeper 需要一种能够支持顺序一致性、快速恢复以及高效领导者选举的协议。虽然 Paxos 提供了一致性，但它并不直接支持这些特性。因此，Zookeeper 团队设计了 ZAB，它更专注于满足 Zookeeper 的具体需求，如高效的领导者选举和事务日志同步。

• 简化操作：ZAB 协议简化了许多操作，比如通过引入一个持久的领导者来减少决策过程中的复杂性，并确保所有更新都按全局一致的顺序执行。此外，ZAB 还实现了原子广播功能，这对于 Zookeeper 所需的分布式协调服务非常重要。

• 容错机制：ZAB 设计了更为直观的容错机制，可以在部分节点失效的情况下继续运作，同时允许失效节点重新加入集群后快速同步状态，这比直接应用 Paxos 更加高效和实用。

三、ZAB简介

1.名词解释

在 ZAB（Zookeeper Atomic Broadcast）协议中，提案（Proposal）、事务（Transaction）和原子广播（Atomic Broadcast）是三个核心概念。

提案（Proposal）

提案是指由 Zookeeper 集群中的领导者发起的一个变更提议。每个提案包含了客户端请求的具体操作（如创建节点、删除节点等），以及一个唯一的序列号，用来确保所有提案按照全局一致的顺序被处理。

事务（Transaction）

在 ZAB 的上下文中，事务指的是对 Zookeeper 状态的一次或多次更改的集合。一次事务可以包含多个操作（例如创建多个 znode 或修改现有 znode 的数据），但这些操作被视为一个不可分割的整体。
事务具有原子性，即事务中的所有操作要么全部成功执行，要么完全不执行。这保证了即使在网络故障或其他异常情况下，系统的状态仍然保持一致。

原子广播（Atomic Broadcast）

原子广播是 ZAB 协议的核心功能之一，它确保了所有集群成员以相同的顺序接收并应用相同的消息（即提案）。这意味着一旦一个消息被广播给所有成员，那么这个消息最终会被所有正常工作的成员接收到，并且不会有任何成员接收到部分消息或不同版本的消息。

原子性 指Follower要么全部批准，要么全部拒绝。

2.集群角色

在 ZAB（Zookeeper Atomic Broadcast）协议中，集群中的每个节点（也称为服务器或成员）都可以扮演不同的角色。这些角色对于确保集群的正常运作、数据一致性和高可用性至关重要。以下是 ZAB 协议中常见的集群角色：

领导者（Leader）

• 职责：
  • 负责接收来自客户端的所有写请求，并将这些请求转化为提案（Proposal），然后广播给所有跟随者。
  • 管理提案的提交过程，确保所有跟随者按照全局一致的顺序处理提案。

跟随者（Follower）

• 职责：
  • 接收来自领导者的提案，并对提案进行投票确认。
  • 如果大多数跟随者同意了某个提案，则该提案会被提交并应用到本地状态机上。
  • 跟随者也会转发读请求给领导者处理，但可以直接响应只读请求（在某些配置下）。

观察者（Observer）

• 职责：
  • 类似于跟随者，观察者也会接收来自领导者的提案，并同步其状态。
  • 然而，观察者不会参与投票过程，因此它们的存在不影响法定人数（Quorum）的计算。
  • 主要用于扩展 Zookeeper 集群的读取能力，减轻领导者和跟随者的负载。

3.成员状态

ZAB（ZooKeeper Atomic Broadcast）协议是ZooKeeper用来实现分布式一致性的一个关键组件。它确保所有服务器能够就一系列更新达成一致，即使在某些服务器故障的情况下也是如此。ZAB协议定义了几个成员状态：

ELECTION：

• 当集群中的领导者（Leader）宕机或与大多数Follower失去联系时，ZooKeeper进入ELECTION状态。
• 在这个状态下，每个服务器都认为自己可能是新的领导者，并尝试选举一个新的领导者。
• 一旦选出了新的领导者，所有参与者将从ELECTION状态转移到FOLLOWING或LEADING状态。

LEADING：

• 只有一个服务器可以处于LEADING状态，即当前的领导者。
• 领导者负责协调所有的写操作，确保它们被正确地广播到所有的Follower。
• 领导者还负责发起和协调新的选举过程，如果它检测到自己不再是多数派的一员。

FOLLOWING：

• 大部分服务器会处于FOLLOWING状态，作为跟随者（Follower）。
• 跟随者接收来自客户端的读请求并直接处理它们（因为ZooKeeper的数据模型是可复制的），而对于写请求，则转发给领导者。
• 它们也接收来自领导者的提议（Proposal）并且应用这些提议以保持数据的一致性。

OBSERVING：

• 这个状态是在加入新成员或重新连接断开成员时使用的一种特殊状态。
• 观察者（Observer）不参与选举，但它们会像跟随者一样接收和处理来自客户端的请求以及来自领导者的提议。
• 观察者帮助分担读取负载而不影响写入路径的一致性决策。

4.运行阶段

ZAB（Zookeeper Atomic Broadcast）协议的运行过程可以分为几个关键阶段，这些阶段确保了集群中数据的一致性和高可用性。以下是 ZAB 协议的主要运行阶段：

（1）Leader Election（领导者选举阶段）

• 触发条件：当 Zookeeper 集群启动时或当前领导者失效时。
• 过程：
  • 所有服务器尝试成为领导者，通过一个协商过程来决定哪个服务器将成为新的领导者。
  • 每个服务器会广播自己的提议，并收集其他服务器的投票。
  • 如果一个服务器获得了超过半数的票数（即法定人数），它就成为新的领导者。
  • 新的领导者将同步其状态与最完整的事务日志副本保持一致。

（2）Discovery（发现阶段）

• 描述：新选出来的领导者进入此阶段，以确保所有跟随者都知道谁是新的领导者，并且所有跟随者都同意领导者的最新状态。
• 过程：
  • 领导者向所有跟随者发送心跳消息，确认它们的状态。
  • 跟随者回复它们最后处理的事务 ID，以便领导者了解每个跟随者的状态。
  • 领导者根据跟随者的反馈确定需要发送给每个跟随者的最小事务集，以使它们的状态与自己同步。

（3）Synchronization（同步阶段）

• 描述：在这个阶段，领导者确保所有跟随者的状态与其自身一致。
• 过程：
  • 领导者发送必要的缺失事务给跟随者，以更新它们的状态。
  • 跟随者应用这些事务并确认完成。
  • 当大多数跟随者（法定人数）确认后，领导者认为集群已经同步完成。

（4）Broadcast（广播阶段）

• 描述：一旦集群同步完成，领导者开始正常接收和处理客户端请求。
• 过程：
  • 领导者接收来自客户端的写请求，将其转化为提案（Proposal），并广播给所有跟随者。
  • 跟随者对收到的提案进行投票确认。
  • 如果大多数跟随者同意，则该提案被提交，所有成员按照相同的顺序应用这个提案。
  • 对于读请求，跟随者可以直接响应，而不需要经过领导者（在某些配置下）。

ZAB协议中的消息广播类似于两阶段提交（2PC）的过程， 因为它同样依赖于一个领导者来协调所有跟随者的行动，并通过两个主要阶段确保数据的一致性：首先，领导者将提议的消息广播给所有跟随者并等待它们的确认（类似于2PC的准备阶段）；一旦收到大多数跟随者的确认，领导者就会通知所有节点应用该消息，从而完成广播（类似于2PC的提交阶段）。这种机制保证了即使在部分节点故障的情况下，系统仍能维持一致性和可用性。
但是，ZAB采用了一种更简单的两阶段过程： 提议阶段和提交阶段。领导者一旦收到大多数跟随者的确认，就可以立即通知所有节点应用提议。而2PC需要额外的准备阶段来询问每个参与者是否可以执行操作，这增加了延迟。消息广播还移除了第二阶段的中断逻辑，所有的Follower要么批准每一个Proposal，要么抛弃Leader服务器。

Commit（提交阶段）

• 描述：当一个提案获得法定人数的认可后，它就会被提交。
• 过程：
  • 领导者通知所有跟随者提交该提案。
  • 每个跟随者将提案应用于本地状态机，并更新其状态。
  • 提交完成后，提案所代表的操作正式生效。

Observer Handling（观察者处理）

• 描述：观察者不参与投票，但仍然需要保持最新的状态。
• 过程：
  • 观察者从领导者那里接收提案并应用到本地状态机上。
  • 它们可以响应只读请求，但不会影响法定人数的计算。

5.事务标识符

ZAB（ZooKeeper Atomic Broadcast）协议中的事务标识符 zxid 是一个非常重要的概念，它用于唯一标识每个事务，并确保事务的顺序性。zxid 是一个64位的数字，由两部分组成：

1. EPOCH (32位)：表示领导者的周期或者任期。每当选举出一个新的领导者时，EPOCH会增加。这有助于区分不同领导者的提议，即使它们在不同的任期内提出了相同的本地序列号。

2. COUNT (32位)：是领导者提出的事务在其任期内的递增计数器。每次领导者提出新的提议时，COUNT都会增加。这意味着在同一任期内，COUNT可以用来对提议进行排序。

作用

• 唯一性：由于zxid结合了EPOCH和COUNT，因此它可以保证每个事务在整个集群中都是唯一的。
• 全局有序：通过zxid，可以确保所有服务器上的事务按照相同的顺序被应用，这对于维护数据的一致性和正确性至关重要。
• 故障恢复：当一个新的领导者被选出来之后，它可以通过比较zxid来确定哪些事务已经被确认，哪些还没有，从而能够安全地继续处理未完成的事务。

示例

假设我们有一个初始的zxid为0x0000000100000001，这里前32位是EPOCH（0x00000001），后32位是COUNT（0x00000001）。如果这个领导者发起了两个事务，那么第二个事务的zxid将会是0x0000000100000002。如果此时发生了领导者变更，新的领导者的EPOCH将变为0x00000002，而它的第一个事务的zxid可能是0x0000000200000001。