Zookeeper数据一致性(ZAB协议)

本文深入解析Zookeeper的ZAB协议,探讨其如何确保分布式系统中数据的一致性,包括事务处理、异常恢复、数据同步机制及与Paxos协议的对比。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

分布式  主导CAP 理论,系统一致性,可用性,以及分区容错性。虽然 实际中  三者一般 不可尽善尽美,但 多多益善 最好。上篇 的 集群选举  多是 分区容错性 ,即 多节点服务  ,某服务 不可用 ,可 尽快恢复。 本篇 则主要 数据一致性 问题,且 在某些 场景中  数据的一致性 有可能 高于其他。


分布式系统 ,对 多副本数据 一致性这块 ,有多种 基础方案 ,如 Lease机制 (为 数据颁发lease 有限时间 ),Quorum机制(类似 过半数概念,认为一般 读取过半数的副本 至少有一个最新的数据服务)等。虽然 几种机制 并非完美,但后续 均有借鉴。 本文 Zookeeper 的ZAB 也有 上述几种机制的影子。

ZAB协议(Zookeeper Atomic Broadcast, 原子消息广播协议),参考 Paxos 的 强一致性 协议。

 

1. ZAB 协议规定

  (1) 一个 事务在一台 机器上处理成功,则 在所有机器上均处理成功,哪怕 机器故障。

  (2) 在Leader 上 提交的事务 , 将被 所有服务器 提交。

  (3) 丢弃那些  只在Leader 上提出 并未 提交的事务。

2. ZAB 协议 过程

    对于 读请求 , 每个 节点 服务 均一致

    对于 写请求,处理如下:

    所有 事务 必须转交 Leader  -->  Leader 分配全局单调递增 事务zxid ,并 广播提议

    -->   Followers 处理提议,做出反馈   -->   Leader 收到 过半反馈,广播 提交 commit

   -->    Leader 根据 情况  做出响应,对外提供服务

3.  异常 --- 崩溃恢复

   若 Leader 失去 半数的 支持, 则进入 崩溃恢复模式,重新 选举Leader。选举 最高zxid 成为Leader。保留 已经提交的提议, 丢弃 仅在Leader 提出的提议。

4.  丢弃 老提议处理

  zxid  高32位  为纪元值,出现 新Leader 就会+1 (类似 Pasox  选举轮数),而 低 32位 为该次选举 提议数。

  若 Leader  发现 ,Followers 中  存在 比自己 小的纪元值 (上一选举Leader 遗留未完成的事务),则要丢弃,同步 当前Leader的 值。

5. 数据 同步

Leader  为每个 Follower 准备 一个FIFO 队列  -->  将未 被同步的事务 逐个发给 Follower (理论 上Leader 拥有当前最新的值) -->  发布 commit 消息, 表示该事务 已被提交  --->  Follower同步完后,即可 加入Leader 可用列表 对外提供服务。

6. ZAB 与 Paxos

其实 两者 异曲同工,  在 提议 提交 阶段, ZAB 协议 会简单点  只有Leader 可以 自增 id  而 Paxos  每个提议者 均可自增

7.  其他

zookeeper 的 临时节点 , 心跳检测 , 即 类似  Lease 机制

zookeeper  本身 对 各个服务节点 而言  均 FIFO  , 所以 也是 符合 Quorum的

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值