Zookeeper数据一致性（ZAB协议）

分布式  主导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的