什么是 Zab 协议？解析 ZooKeeper 如何通过原子广播保证数据更新的顺序性 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

分布式系统中的数据一致性挑战

在现代分布式系统中，如何确保数据的一致性、可靠性和顺序性，是构建稳健应用面临的核心挑战之一。随着业务规模的扩张，单点服务的瓶颈日益凸显，分布式架构成为必然选择。然而，在多个独立节点之间协调操作、同步状态，并保证所有节点对数据的认知保持一致，其复杂性呈指数级增长。网络延迟、节点故障、并发访问等问题，都可能导致数据不一致，进而引发严重的业务逻辑错误。

ZooKeeper，作为一个开源的分布式协调服务，旨在解决这些复杂性。它提供了一套简单而强大的原语，如分布式锁、配置管理、命名服务、组服务等，帮助开发者更容易地构建分布式应用。ZooKeeper之所以能够提供这些可靠的服务，其基石在于它能够保证所有对共享状态的更新都以一个严格的、全局的顺序进行处理。实现这一目标的关键，正是其内部采用的 Zab（ZooKeeper Atomic Broadcast）协议。

Zab协议本质上是一种原子广播（Atomic Broadcast）协议，它确保了在ZooKeeper集群中的所有活动服务器，都以相同的顺序接收和处理相同的更新事务。这意味着，无论客户端请求发送到哪个ZooKeeper服务器，更新操作最终都会在所有服务器上以相同的顺序提交。这种强一致性保证，是ZooKeeper能够提供可靠协调服务的前提。

认识 ZooKeeper: 分布式协调服务的基石

在深入探讨 Zab 协议之前，我们首先需要对 ZooKeeper 有一个清晰的认识。ZooKeeper 提供了一个高性能、高可用的分布式数据存储，其数据模型类似于一个标准的文件系统。

数据模型:
ZooKeeper 的数据存储结构是一个树形层级命名空间，类似于文件系统中的目录和文件。每个节点被称为一个 znode。

路径: 每个 znode 都由一个唯一的路径标识，例如 /config/app1/db_url。
数据: znode 可以存储少量数据（通常是配置信息、状态信息等）。
版本: 每个 znode 都有版本号。对 znode 数据或子节点的任何更改都会导致其版本号增加。这对于乐观锁和条件更新至关重要。
类型: znode 分为持久节点（Persistent）、临时节点（Ephemeral）和顺序节点（Sequential）。
- 持久节点: 一旦创建就一直存在，除非被客户端明确删除。
- 临时节点: 与创建它的客户端会话绑定。当客户端会话结束时，临时节点会被自动删除。常用于实现服务注册与发现、分布式锁等。
- 顺序节点: 在创建时，ZooKeeper 会给该节点的路径末尾添加一个单调递增的计数器。这对于实现分布式队列、领导者选举等场景非常有用。

ZooKeeper 的关键特性与保证:
ZooKeeper 提供的核心保证，正是其能够作为分布式协调服务基石的原因：

顺序一致性（Sequential Consistency）: 客户端的更新操作将按照它们被发出的顺序应用。这要求所有服务器以相同的顺序处理事务。
原子性（Atomicity）: 任何一个更新操作要么成功，要么失败，不存在部分成功。所有服务器要么都应用这个更新，要么都不应用。
单一系统镜像（Single System Image）: 无论客户端连接到哪个服务器，它看到的都是相同的数据视图。
持久性（Durability）: 一旦一个更新被应用并被多数服务器确认，即使发生服务器故障，这个更新也不会丢失。

这些保证都高度依赖于底层协议能够实现对数据更新的严格顺序性，而这正是 Zab 协议的核心任务。

Zab 协议的核心思想

Zab 协议，即 ZooKeeper Atomic Broadcast 协议，是 ZooKeeper 用来在集群中实现数据一致性和事务全序性（total ordering）的核心。它的目标是确保所有 ZooKeeper 服务器都以相同的顺序处理并提交客户端提交的更新请求。这被称为“原子广播”，因为一个事务要么被所有服务器接受并提交，要么被所有服务器抛弃。

Zab 协议是一个领导者-追随者（Leader-Follower）模式的协议。在任何给定时间，ZooKeeper 集群中只有一个服务器被选举为 领导者（Leader）。所有客户端的写请求都必须经过领导者来处理。领导者负责接收客户端的更新请求，为其分配一个全局唯一的事务 ID (zxid)，然后将这些请求以提案（Proposal）的形式广播给所有追随者（Follower）。追随者接收提案，并将其写入本地事务日志，然后向领导者发送确认（Acknowledgement）。当领导者收到多数追随者的确认后，它就认为该事务可以被提交，并通知所有追随者执行提交操作。

Zab 协议的整个生命周期可以分为两个主要阶段：恢复阶段（Recovery Phase）和广播阶段（Broadcast Phase）。恢复阶段主要发生在系统启动或领导者选举之后，目的是为了选举出新的领导者，并确保所有服务器的状态达成一致。广播阶段是系统正常运行时的主要阶段，负责处理客户端的更新请求并将其原子地广播到整个集群。

Zab 协议的组成部分与角色

在 Zab 协议中，集群中的每个 ZooKeeper 服务器都扮演着特定的角色：

领导者（Leader）:
- 在任何时刻，集群中只有一个领导者。
- 负责处理所有客户端的写请求。
- 为每个更新请求生成一个唯一的 zxid。
- 将更新请求转换为提案（Proposal）。
- 协调提案的广播和提交过程，等待多数追随者的确认。
- 在恢复阶段，负责同步追随者的数据。
追随者（Follower）:
- 集群中除领导者外的其他服务器。
- 接收并处理客户端的读请求（可以从本地副本读取）。
- 将所有客户端的写请求转发给领导者。
- 接收领导者广播的提案，将其写入本地事务日志，并向领导者发送确认。
- 在领导者指示提交后，将事务应用到自己的内存状态。
- 参与领导者选举过程。
观察者（Observer）:
- 观察者是一种特殊的追随者。
- 它们也接收并处理客户端的读请求，并将写请求转发给领导者。
- 它们会接收领导者广播的提案，但不参与投票过程（即不向领导者发送确认）。
- 观察者的主要目的是提高 ZooKeeper 集群的读取吞吐量和扩展性，同时不增加选举和事务提交的开销（因为它们不增加法定人数的要求）。它们通常部署在远离核心数据中心的边缘区域，提供本地读服务。
法定人数（Quorum）:
- ZooKeeper 集群要正常运行，需要至少 (n/2) + 1 个服务器处于可用状态，其中 n 是集群中服务器的总数（不包括观察者）。这个多数派被称为“法定人数”或“法定数量”。
- Zab 协议的正确性高度依赖于法定人数。领导者只有在收到法定人数的追随者确认后，才能提交事务。
- 法定人数的存在保证了在任何时刻，最多只能有一个领导者被选举出来，并且已提交的数据不会丢失。如果一个事务被法定人数的服务器确认并提交，那么即使部分服务器崩溃，剩余的多数派服务器也一定包含这个已提交的事务，从而可以在恢复时保持数据一致性。

Zab 协议的两个主要阶段

Zab 协议的运作可以分为两个核心阶段：恢复阶段和广播阶段。

5.1. 恢复阶段 (Recovery Phase)

恢复阶段是 Zab 协议的启动阶段，或在领导者失效后重新选举和同步的阶段。其主要目标是：

选举出一个新的领导者。
确保新领导者的事务日志是最新且完整的，包含所有已提交的事务。
将所有追随者的状态同步到与新领导者一致。

恢复阶段又包含两个子阶段：领导者选举和数据同步。

5.1.1. 领导者选举 (Leader Election)

当 ZooKeeper 集群启动时，或者当前领导者崩溃时，集群会进入领导者选举阶段。所有服务器会尝试选举一个新的领导者。

选举过程概述:
每个服务器都会投票给它认为最合适的服务器作为领导者。最合适的服务器通常是拥有最新已提交事务的服务器。ZooKeeper 使用一个名为 zxid（ZooKeeper Transaction ID）的64位数字来标识事务的顺序。zxid 的结构是 epoch << 32 | counter：

epoch (纪元): 每次选举出一个新的领导者，epoch 就会递增。这确保了在不同领导者任期内的事务顺序。
counter (计数器): 在一个 epoch 内，每次事务更新都会使 counter 递增。

选举的规则是：

优先选择 zxid 最大的服务器: 拥有最大 zxid 的服务器意味着它拥有最新的数据。
如果 zxid 相同，则选择 myid 最大的服务器: myid 是 ZooKeeper 集群中每个服务器的唯一标识符。这是一种决胜规则，确保在 zxid 相同的情况下也能选出唯一的领导者。

选举流程:

自投票: 每个服务器启动时，会首先投票给自己。
广播投票: 服务器将自己的投票（包含候选服务器的 zxid 和 myid）广播给集群中的其他服务器。
接收投票与更新投票: 服务器接收来自其他服务器的投票。如果收到的投票中的候选服务器比当前自己投票的服务器更优（根据 zxid 和 myid 规则），它会更新自己的投票，并重新广播。
统计投票: 当一个服务器收到的票数达到法定人数，并且这些票都投给了同一个候选服务器时，那么该候选服务器就被选举为新的领导者。

简化伪代码示例 (投票逻辑):

class Vote {
    long zxid;    // 候选服务器的最新事务ID
    long serverId; // 候选服务器的myid
}

class Server {
    long myid;
    long currentZxid; // 本服务器的最新zxid
    Map<Long, Vote> receivedVotes; // 存储收到的所有投票
    Vote myVote;

    void startLeaderElection() {
        myVote = new Vote(currentZxid, myid);
        broadcastVote(myVote);

        // 持续接收投票并更新
        while (!leaderElected()) {
            Vote remoteVote = receiveVote(); // 模拟接收一个投票
            if (remoteVote != null) {
                receivedVotes.put(remoteVote.serverId, remoteVote);

                // 比较并可能更新自己的投票
                if (isBetterCandidate(remoteVote, myVote)) {
                    myVote = remoteVote; // 更新自己的投票为更优的候选者
                    broadcastVote(myVote); // 广播新的投票
                }
            }
        }
    }

    // 判断哪个候选者更优
    boolean isBetterCandidate(Vote candidate1, Vote candidate2) {
        if (candidate1.zxid > candidate2.zxid) {
            return true;
        } else if (candidate1.zxid == candidate2.zxid && candidate1.serverId > candidate2.serverId) {
            return true;
        }
        return false;
    }

    // 检查是否已选出领导者 (伪代码，实际需要统计多数票)
    boolean leaderElected() {
        // 遍历 receivedVotes，统计哪个候选者获得了多数票
        // 如果有一个候选者获得 (n/2)+1 票，则返回 true
        // 否则返回 false
        return false; // 简化处理
    }
}

5.1.2. 数据同步 (Synchronization)

一旦新的领导者被选举出来，它会进入数据同步阶段。在这个阶段，领导者负责确保所有追随者的状态都与自己保持一致。

同步过程:

领导者识别最新状态: 新领导者会检查自己的事务日志，确定它所拥有的最新已提交的 zxid。它还会从所有连接的追随者那里获取它们的最新 zxid。
追随者与领导者同步:
- 回退（Truncation）: 如果某个追随者的 zxid 比领导者的大（这通常发生在旧领导者崩溃，而某些事务在旧领导者上被提议但未被多数派提交的情况下），那么追随者需要回退其日志，删除那些未被多数派提交的事务，直到与领导者的 zxid 一致。
- 追赶（Catch-up）: 如果某个追随者的 zxid 比领导者小，那么它需要从领导者那里获取缺失的事务，并将其应用到自己的状态中，直到与领导者完全同步。领导者会根据追随者提供的 zxid，从自己的事务日志中发送从该 zxid 之后的所有事务给追随者。
发送 NEW_EPOCH 提案: 当所有追随者都与领导者同步完毕后，领导者会向所有追随者广播一个特殊的 NEW_EPOCH 提案。这个提案的 zxid 将包含新的 epoch 号，counter 部分为0。
确认 NEW_EPOCH: 所有追随者接收到 NEW_EPOCH 提案后，会将其写入本地事务日志，并向领导者发送确认。
进入广播阶段: 当领导者收到法定数量的追随者对 NEW_EPOCH 提案的确认后，恢复阶段结束，集群进入广播阶段，可以开始正常处理客户端的写请求。

通过这两个子阶段，Zab 协议确保了在开始处理新的客户端请求之前，集群中的所有服务器都拥有一个一致且最新的状态，并且已经选出了一个唯一的领导者来协调未来的更新。

5.2. 广播阶段 (Broadcast Phase)

广播阶段是 Zab 协议的正常运行阶段，此时领导者已选举完毕且所有服务器已同步。在这个阶段，领导者负责接收客户端的写请求，并使用原子广播机制将其安全、有序地提交到所有服务器。

广播流程 (Two-Phase Commit Like):
尽管 Zab 协议不是严格意义上的两阶段提交（2PC），但其核心思想与2PC有相似之处，即通过两个阶段（提案-确认，提交-执行）来保证原子性。

客户端请求: 客户端向集群中的任意一个 ZooKeeper 服务器发送一个更新请求（例如 create znode, setData, delete znode）。
请求转发: 如果客户端连接的服务器不是领导者，它会将该更新请求转发给当前的领导者。如果客户端直接连接到领导者，则跳过此步。

领导者生成提案 (Proposal):

领导者接收到更新请求后，会对其进行预处理，生成一个新的 zxid。这个 zxid 是在当前 epoch 下单调递增的。
领导者将更新请求封装成一个 PROPOSAL 消息，其中包含新的 zxid 和要执行的数据修改操作。
zxid 的生成是保证全局顺序的关键。领导者每次处理一个事务，zxid 的 counter 部分就会加一。

// 简化领导者处理客户端写请求的逻辑
class Leader {
    long currentEpoch;
    long currentCounter;
    List<Transaction> pendingProposals; // 等待提交的提案

    long generateNewZxid() {
        return (currentEpoch << 32) | (++currentCounter);
    }

    void handleClientWriteRequest(ClientRequest request) {
        long newZxid = generateNewZxid();
        Transaction transaction = new Transaction(newZxid, request.getData(), request.getOp());
        pendingProposals.add(transaction);

        // 广播提案给所有追随者
        broadcastProposal(transaction);
    }
}

广播提案: 领导者将 PROPOSAL 消息发送给所有注册的追随者。
追随者确认 (Acknowledgement):
- 每个追随者收到 PROPOSAL 消息后，不会立即执行这个事务。
- 它会将这个 PROPOSAL 写入自己的本地事务日志（WAL – Write Ahead Log），确保即使在提交前崩溃也能恢复。
- 一旦成功写入日志，追随者就会向领导者发送一个 ACK（Acknowledgement）消息，表示它已接收并持久化了这个提案。
```
// 简化追随者处理提案的逻辑
class Follower {
    TransactionLog log; // 本地事务日志

    void receiveProposal(Transaction proposal) {
        log.write(proposal); // 将提案写入本地日志
        sendAckToLeader(proposal.getZxid()); // 向领导者发送确认
    }
}
```

领导者提交 (Commit):

领导者等待，直到收到法定数量（quorum）的追随者对该 PROPOSAL 的 ACK。
一旦收到多数 ACK，领导者就认为这个事务已经达成共识，可以安全提交。
领导者会首先将该事务应用到自己的内存状态中。
然后，领导者向所有追随者广播一个 COMMIT 消息，通知它们提交该事务。

// 简化领导者提交逻辑
class Leader {
    Map<Long, Set<Long>> ackedFollowers; // zxid -> Set<followerId>

    void processAck(long zxid, long followerId) {
        ackedFollowers.computeIfAbsent(zxid, k -> new HashSet<>()).add(followerId);

        if (ackedFollowers.get(zxid).size() >= getQuorumSize()) {
            // 找到对应的提案
            Transaction committedTx = findTransactionByZxid(zxid);
            applyTransactionToState(committedTx); // 领导者本地提交
            broadcastCommit(committedTx); // 通知所有追随者提交
            // 清理 pendingProposals 和 ackedFollowers
        }
    }
}

追随者执行 (Execute):

追随者收到 COMMIT 消息后，会将其从本地事务日志中读取出来（如果尚未读取），并将其应用到自己的内存状态中。
至此，该事务在所有参与提交的服务器上都已生效。
最终，ZooKeeper 会向最初发起请求的客户端发送一个响应，告知操作结果。

// 简化追随者执行提交逻辑
class Follower {
    StateStore stateStore; // 内存状态存储

    void receiveCommit(Transaction transaction) {
        // 从日志中读取或直接应用 (如果已在内存)
        stateStore.apply(transaction); // 将事务应用到内存状态
        // 可以通知客户端 (如果它最初连接到此Follower)
    }
}

这个过程确保了：

原子性: 事务要么在多数派上全部提交，要么全部不提交。如果领导者在收到法定数量 ACK 之前崩溃，该事务不会被提交，并在下次恢复时被回滚。
顺序性: 由于所有写请求都经过唯一的领导者，并由领导者分配 zxid 进行广播，所有服务器都将按照 zxid 的严格顺序处理事务。

Zab 协议如何保证数据更新的顺序性

Zab 协议通过其独特的设计，从多个层面保障了 ZooKeeper 集群中数据更新的严格顺序性、原子性、持久性和可靠性。

6.1. 全序性 (Total Order)

全序性是 Zab 协议最核心的保证之一，它确保所有 ZooKeeper 服务器都以完全相同的顺序处理和应用所有的更新事务。

单一领导者 (Single Leader): 在任何给定时刻，集群中只有一个领导者负责接收和协调所有写请求。这天然地将所有更新操作串行化，避免了并发冲突。领导者是事务序列的唯一来源。
顺序 zxid (Sequential zxid): 领导者为每个新的更新事务分配一个全局唯一的、单调递增的 zxid。这个 zxid 结合了 epoch 和 counter，确保了跨领导者选举和在一个领导者任期内的事务的严格顺序。所有服务器都必须按照 zxid 的顺序来处理事务。
法定人数确认 (Quorum Acknowledgment): 一个事务只有在被法定数量的追随者确认（写入本地事务日志）后，才会被领导者标记为可提交。这意味着在事务被正式提交之前，已经有足够多的服务器“同意”并记录了这个事务。这防止了在网络分区或部分服务器故障时，不同子集服务器对事务顺序产生不同认知。
恢复阶段的同步: 在领导者选举后，所有服务器会进行严格的数据同步。新领导者会将其日志中最新已提交的事务作为基准，所有追随者要么回退多余的事务，要么追赶缺失的事务，最终达到与领导者完全一致的状态。这保证了在广播新事务之前，集群已经处于一个一致的起点。

6.2. 原子性 (Atomicity)

Zab 协议确保事务的原子性，即一个更新操作要么在所有（多数派）服务器上完全成功，要么完全失败，不存在部分成功的情况。

两阶段提交式流程: 提案的广播和提交分为两个阶段。领导者只有在收到法定数量的 ACK 后，才会向所有追随者发送 COMMIT 消息。
写前日志 (WAL): 追随者在发送 ACK 之前，必须将提案写入本地的持久化事务日志。如果追随者在接收 COMMIT 消息之前崩溃，其日志中仍然保留了提案。在恢复时，它会根据领导者的最新状态决定是提交（如果领导者已提交）还是回滚（如果领导者尚未提交）。
法定人数保障: 如果一个事务被法定数量的服务器持久化并提交，那么即使部分服务器崩溃，剩余的多数派仍然拥有这个事务的记录，从而在恢复时可以保证原子性。

6.3. 持久性 (Durability)

Zab 协议通过事务日志保证了数据的持久性。

事务日志 (Transaction Log): 所有更新事务在被追随者 ACK 之前，都必须写入到本地的磁盘事务日志中。一旦领导者宣布事务提交，就意味着该事务至少已被法定数量的服务器写入持久存储。
快照 (Snapshots): 为了防止事务日志无限增长，ZooKeeper 会定期对内存中的数据状态进行快照。快照是某个 zxid 时刻的完整数据视图。在恢复时，服务器可以从最新的快照开始，然后重放快照之后的所有事务日志，快速恢复到最新状态。

6.4. 可靠性 (Reliability)

Zab 协议确保一旦一个事务被提交，它最终会被所有非故障的副本交付和应用。

重试机制: 领导者在发送 COMMIT 消息后，如果某些追随者没有及时响应，领导者会周期性地重发 COMMIT 消息，直到所有追随者都确认应用。
恢复机制: 即使有服务器在提交过程中崩溃，Zab 的恢复阶段也能保证在新的领导者选举后，所有服务器的状态最终会达到一致。任何在故障前已提交但未被所有服务器应用的事务，都会在新领导者的协调下被应用。未被多数派提交的事务则会被回滚。

通过这些机制的协同作用，Zab 协议为 ZooKeeper 提供了强大的数据一致性保证，使其成为构建高可靠分布式系统的理想选择。

Zab 协议的实现细节与优化

在实际的 ZooKeeper 实现中，Zab 协议还包含了一些重要的细节和优化，以提高性能和稳定性。

事务日志与快照管理:
- dataDir 和 dataLogDir: ZooKeeper 允许将事务日志和快照文件存储在不同的磁盘上。通常推荐将 dataLogDir（事务日志）放在独立的、高性能的磁盘上，因为事务日志的写入是所有写操作的瓶颈。
- fsync: 为了确保数据真正落盘，ZooKeeper 会在写入事务日志后进行 fsync 操作。这虽然会带来一定的性能开销，但对于数据持久性至关重要。
- 日志清理: 随着时间的推移，事务日志会不断增长。ZooKeeper 通过定期创建快照并清理旧的事务日志来管理磁盘空间。当一个快照创建完成后，所有早于该快照 zxid 的事务日志文件都可以被安全删除。
管道化 (Pipelining) 提案:
- 为了提高吞吐量，Zab 协议允许领导者在收到前一个提案的法定数量 ACK 之前，就发送下一个提案。这意味着多个提案可以“在管道中”等待确认。
- 追随者也会按照接收到的顺序处理这些提案，并按序发送 ACK。
- 领导者会跟踪每个提案的 ACK 情况，只有当一个提案及其之前的所有提案都已收到法定数量 ACK 时，领导者才会发送该提案的 COMMIT 消息。这种机制在保证顺序性的同时，显著提升了系统的吞吐量。
读请求处理:
- ZooKeeper 允许追随者处理客户端的读请求。这分担了领导者的压力，提高了读取的扩展性。
- 一致性保证: 追随者在处理读请求时，默认提供的是“可能过期”的数据（eventual consistency）。如果客户端需要读取最新的数据（sync），它可以向服务器发送一个 sync 命令。服务器收到 sync 命令后，会确保在响应客户端之前，将其本地状态与领导者同步到最新已提交的事务。
- syncLimit 和 initLimit 配置参数：这些参数控制了追随者与领导者之间允许的最大心跳延迟以及启动同步的超时时间，间接影响了读请求能够获得数据的新旧程度。
观察者 (Observers):
- 观察者不参与领导者选举和投票，因此不会增加法定人数的开销。
- 它们主要用于扩展 ZooKeeper 的读服务能力，可以部署在地理位置分散的数据中心，为本地客户端提供低延迟的读取服务。
- 观察者从领导者那里接收事务更新，并将其应用到本地，但不对领导者进行 ACK。这使得它们成为一种轻量级的副本。
会话管理 (Session Management):
- ZooKeeper 的所有客户端连接都被抽象为会话。会话有一个超时时间。
- 领导者负责维护所有活动会话的状态，包括会话心跳和临时节点的生命周期。
- 当一个客户端会话超时，领导者会发起一个事务来删除该会话创建的所有临时节点，并将这个事务通过 Zab 协议广播到整个集群。这确保了临时节点的原子性删除。

Zab 与其他一致性协议的对比

理解 Zab 协议的独特之处，有助于将其与分布式系统中其他常见的一致性协议进行比较。

8.1. Zab vs. Paxos

Zab 协议在很多方面与 Paxos 协议（特别是 Multi-Paxos）非常相似。Paxos 是一种理论上可以解决分布式一致性问题的通用算法。

相似之处:

领导者-副本模式: 两者都采用领导者（或提案者）和副本（或接受者）的角色。
多数派决策: 都依赖于多数派（Quorum）的确认来提交一个值。
两阶段提交思想: 都涉及提案和确认两个主要阶段。

主要区别:

特定用途: Paxos 是一种通用的分布式一致性算法，可以用于任意值的共识。Zab 是为 ZooKeeper 的特定需求（即原子广播一组有序的事务）而设计的，它专注于日志的顺序复制和状态机复制。
领导者选举与恢复: Zab 协议明确地将领导者选举和恢复阶段集成到协议中，并定义了详细的 zxid 和 epoch 机制来处理领导者切换时的状态一致性。Paxos 的领导者选举（或提案者选择）通常被认为是其实现上的一个挑战，需要额外的机制来处理。Zab 的 zxid 机制在处理日志的连续性和新旧领导者切换时的状态同步上，比基础 Paxos 更具体和高效。
日志复制优化: Zab 协议利用了事务日志的顺序性，支持管道化，可以连续发送提案而无需等待前一个提案完全提交。这类似于 Multi-Paxos 的优化，但 Zab 的整体设计更加围绕日志复制和状态机复制展开。
实现复杂度: 普遍认为 Zab 协议在实现上比通用的 Paxos 协议更易于理解和实现，因为它针对特定场景做了简化和优化。Raft 协议的出现也旨在提供一个比 Paxos 更易于理解和实现的替代方案，其核心思想与 Zab 也有很多共同点。

8.2. Zab vs. Raft

Raft 协议是另一种流行的、更易于理解的分布式一致性算法，它也采用领导者-副本模式。

相似之处:

领导者-副本模式: Raft 也有领导者、追随者和候选者角色。
日志复制: Raft 协议的核心也是通过日志复制来保持集群状态一致。
多数派决策: Raft 同样依赖于多数派来提交日志条目。
领导者选举: Raft 有明确的领导者选举过程，使用心跳和随机超时来触发选举。

主要区别:

术语和设计哲学: Raft 旨在“可理解性优先”，其协议步骤和角色定义更加清晰直观。Zab 协议虽然也很强大，但在设计时可能更侧重于 ZooKeeper 的实际需求。
日志匹配属性: Raft 强调“日志匹配属性”，即如果两个日志在相同索引处有相同的条目，那么它们在所有之前索引处的条目也都是相同的。Zab 通过 zxid 和恢复同步机制也达到了类似的效果。
具体实现: Zab 是 ZooKeeper 的内部协议，深度集成在 ZooKeeper 的代码库中。Raft 是一种通用算法，有许多独立实现。

总的来说，Zab、Paxos 和 Raft 都属于通过复制状态机实现强一致性的协议族，它们都在努力解决分布式系统中的共识问题。Zab 是 ZooKeeper 对这一问题的高度优化和具体实现。

8.3. Zab vs. 两阶段提交 (2PC)

两阶段提交（Two-Phase Commit, 2PC）是一种协调分布式事务的经典协议，但它与 Zab 有显著不同。

主要区别:

用途: 2PC 主要用于协调跨多个独立资源管理器（如数据库）的原子性操作。Zab 用于在 ZooKeeper 集群内部实现状态机复制和原子广播。
阻塞性: 2PC 存在单点故障问题和阻塞问题。如果协调者在第二阶段崩溃，参与者可能会无限期地等待提交或回滚指令，导致资源被锁定。Zab 协议通过其领导者选举和恢复机制，提供了更好的可用性，即使领导者崩溃，集群也能通过重新选举和恢复继续提供服务。
一致性模型: 2PC 关注的是事务在多个参与者之间的原子性。Zab 关注的是在集群所有节点上对更新操作的全序性和原子性，以及在此基础上构建的状态机复制。
性能: 2PC 通常开销较大，因为它需要所有参与者都同意才能提交。Zab 通过多数派确认可以更快地提交事务，并且支持管道化，性能更高。

Zab 协议是为高可用和高性能的分布式协调服务量身定制的，它在保证强一致性的同时，通过巧妙的恢复机制和优化手段，避免了传统 2PC 的许多缺点。

实际应用中的 Zab 协议

Zab 协议作为 ZooKeeper 的核心，其在实际部署和运维中扮演着至关重要的角色。

9.1. ZooKeeper 集群部署

奇数节点原则: ZooKeeper 集群通常部署奇数个节点（例如 3、5、7个）。这是因为法定人数要求 (n/2)+1。奇数节点在相同容错能力下（例如，一个5节点的集群可以容忍2个节点失败，一个4节点的集群也只能容忍1个节点失败），效率更高，因为2个节点失败时，5节点集群仍有3个节点存活满足法定人数，而4节点集群只剩2个节点，不足法定人数。
myid 文件: 每个 ZooKeeper 服务器都需要一个 myid 文件，其中包含一个唯一的整数 ID。这个 ID 用于在领导者选举和集群通信中标识服务器。
配置文件: zoo.cfg 文件中包含 tickTime、initLimit、syncLimit、dataDir 和 dataLogDir 等关键参数。
- tickTime: ZooKeeper 使用的基本时间单位（毫秒）。
- initLimit: 追随者在启动时连接并同步领导者的最长时间（以 tickTime 为单位）。
- syncLimit: 追随者与领导者之间允许的最大心跳延迟（以 tickTime 为单位）。如果追随者在 syncLimit 时间内没有响应领导者，它将被认为是故障。
- dataDir: 存储快照文件的目录。
- dataLogDir: 存储事务日志文件的目录（建议独立磁盘）。
- server.X=hostname:port1:port2: 定义集群中每个服务器的地址和端口。port1 用于追随者与领导者之间的通信，port2 用于领导者选举。

9.2. 性能考量

Zab 协议的性能受多种因素影响：

网络延迟: 领导者与追随者之间的网络延迟是事务提交的主要瓶颈，因为它直接影响 PROPOSAL 和 ACK 消息的往返时间。
磁盘 I/O: 追随者在 ACK 之前必须将事务写入持久化日志，因此磁盘的写入性能对吞吐量至关重要。使用 SSD 和独立的 dataLogDir 可以显著改善性能。
集群规模: 随着集群节点数量的增加，领导者需要等待更多 ACK 消息，虽然法定人数不会线性增长，但总体的网络开销会增加。观察者可以帮助扩展读取能力而不增加写操作的开销。
写请求频率: ZooKeeper 的写操作开销相对较高，因为需要通过 Zab 协议进行分布式共识。因此，ZooKeeper 更适合作为协调服务，而不是高吞吐量的消息队列或关系型数据库。

9.3. 故障处理

Zab 协议的健壮性体现在其对各种故障场景的处理能力：

领导者故障: 如果领导者崩溃，集群会立即进入领导者选举阶段，重新选出一个新的领导者，并进行数据同步。整个过程是自动化的，对客户端的写请求会有一小段时间的不可用。
追随者故障: 如果一个或多个追随者崩溃，只要剩余的活动服务器数量仍然满足法定人数，集群就能继续正常运行。故障的追随者恢复后，会重新加入集群，并通过恢复阶段与新领导者同步数据。
网络分区: 如果集群发生网络分区，导致多数派服务器与少数派服务器分离。Zab 协议保证只有多数派分区能够继续选举领导者并提供服务，少数派分区会停止服务，避免数据不一致。这是“CP”（一致性-分区容忍性）系统在 CAP 定理下的典型行为。

Zab 协议是 ZooKeeper 能够稳定运行并成为分布式系统基石的关键。它通过精巧的领导者选举、原子广播和恢复机制，确保了数据的一致性和更新的严格顺序性，为上层分布式应用提供了可靠的协调服务。

ZooKeeper 的 Zab 协议，是分布式系统领域中一个精巧而强大的共识算法实现。它通过独特的领导者选举、zxid 机制以及两阶段提交式的原子广播流程，确保了集群中所有服务器的数据更新严格有序、原子且持久。Zab 不仅为 ZooKeeper 提供了构建各种分布式原语（如锁、队列、配置管理）的基石，也深刻影响了后续分布式一致性协议的设计理念，是理解分布式系统强一致性保证不可或缺的一部分。

分布式系统中的数据一致性挑战

认识 ZooKeeper: 分布式协调服务的基石

Zab 协议的核心思想

Zab 协议的组成部分与角色

Zab 协议的两个主要阶段

5.1. 恢复阶段 (Recovery Phase)

5.1.1. 领导者选举 (Leader Election)

5.1.2. 数据同步 (Synchronization)

5.2. 广播阶段 (Broadcast Phase)

Zab 协议如何保证数据更新的顺序性

6.1. 全序性 (Total Order)

6.2. 原子性 (Atomicity)

6.3. 持久性 (Durability)

6.4. 可靠性 (Reliability)

Zab 协议的实现细节与优化

Zab 与其他一致性协议的对比

8.1. Zab vs. Paxos

8.2. Zab vs. Raft

8.3. Zab vs. 两阶段提交 (2PC)

实际应用中的 Zab 协议

9.1. ZooKeeper 集群部署

9.2. 性能考量

9.3. 故障处理

发表回复 取消回复

发表回复取消回复