ZAB 协议解析：ZooKeeper分布式一致性的核心

最新推荐文章于 2024-06-10 21:00:25 发布

Memory_2020

最新推荐文章于 2024-06-10 21:00:25 发布

阅读量1.2k

点赞数 24

文章标签：架构分布式 zookeeper spring cloud

本文链接：https://blog.csdn.net/EverythingAtOnce/article/details/136326388

版权

在分布式系统中，实现一致性是一个关键的挑战。ZooKeeper作为一个分布式协调服务，在其核心原理中采用了一种名为 ZAB（ZooKeeper Atomic Broadcast）的协议来实现分布式一致性。本文将深入解析 ZAB 协议，揭示其在 ZooKeeper 中实现分布式一致性的核心机制。

1. 协议概述

ZAB 协议全称：Zookeeper Atomic Broadcast（Zookeeper 原子广播协议）。

Zookeeper 是一个为分布式应用提供高效且可靠的分布式协调服务。在解决分布式一致性方面，Zookeeper 并没有使用 Paxos ，而是采用了 ZAB 协议，ZAB是Paxos算法的一种简化实现。

ZAB 协议定义：ZAB 协议是为分布式协调服务 Zookeeper 专门设计的一种支持崩溃恢复和原子广播的协议。下面会重点讲这两个东西。

基于该协议，Zookeeper 实现了一种主备模式的系统架构来保持集群中各个副本之间数据一致性。具体如下图所示：

上图显示了 Zookeeper 如何处理集群中的数据。所有客户端写入数据都是写入到Leader节点，然后，由 Leader 复制到Follower节点中，从而保证数据一致性。

那么复制过程又是如何的呢？复制过程类似两阶段提交(2PC)，ZAB 只需要 Follower(含leader自己的ack) 有一半以上返回 Ack 信息就可以执行提交，大大减小了同步阻塞。也提高了可用性。

简单介绍完，开始重点介绍消息广播和崩溃恢复。整个 Zookeeper 就是在这两个模式之间切换。简而言之，当 Leader 服务可以正常使用，就进入消息广播模式，当 Leader 不可用时，则进入崩溃恢复模式。

2. 消息广播

ZAB 协议的消息广播过程使用的是一个原子广播协议，类似一个两阶段提交过程。对于客户端发送的写请求，全部由 Leader 接收，Leader 将请求封装成一个事务 Proposal，将其发送给所有 Follwer ，然后，根据所有 Follwer 的反馈，如果超过半数(含leader自己)成功响应，则执行 commit 操作。

整个广播流程如下：

通过以上步骤，就能够保持集群之间数据的一致性。

还有一些细节：

Leader 在收到客户端请求之后，会将这个请求封装成一个事务，并给这个事务分配一个全局递增的唯一 ID，称为事务ID（ZXID），ZAB 协议需要保证事务的顺序，因此必须将每一个事务按照 ZXID 进行先后排序然后处理，主要通过消息队列实现。
在 Leader 和 Follwer 之间还有一个消息队列，用来解耦他们之间的耦合，解除同步阻塞。
zookeeper集群中为保证任何所有进程能够有序的顺序执行，只能是 Leader 服务器接受写请求，即使是 Follower 服务器接受到客户端的写请求，也会转发到 Leader 服务器进行处理，Follower只能处理读请求。
ZAB协议规定了如果一个事务在一台机器上被处理(commit)成功，那么应该在所有的机器上都被处理成功，哪怕机器出现故障崩溃。