NingG +

ZooKeeper 技术内幕:消息广播(Zab & Paxos)

背景

ZK Follower/Observer 收到 事务请求后:

  1. 请求转发Follower/Observer事务请求转发到 Leader
  2. 2PC(2 phase commit,两阶段提交):
    • Leader 向所有的 Follower 发送提案(Proposal)
    • Follower将事务信息写入事务队列后, 向 Leader 返回 ACK 确认
    • Leader 接收到法定数量 ACK 后,提交事务请求,并向 Follower/Observer 广播 Commit。

具体,事务执行过程中,提案投票过程见下图:

广播协议:状态更新

上述事务提交的 2PC 策略,实际是由 Zab 协议保证的:

  1. ZAB:ZooKeeper Atomic Broadcast protocol,ZooKeeper 原子广播协议。
  2. 目标:每次事务执行过程,都是原子的,要么成功、要么失败,不存在中间状态;
  3. ZK 中,事务执行过程中,没有回滚机制

ZAB 协议,具体策略:

  1. 事务顺序执行:Leader 确保 T1 事务提交成功后,才会提交事务 T2
  2. Follower 事务顺序执行:所有 Follower 都会先提交 T1,再提交 T2

Note:ZAB 协议,允许:

ZAB 协议

ZK 并没有完全采用 Paxos 算法,而是采用 ZooKeeper Atomic Broadcast(ZAB, ZooKeeper原子广播协议)作为数据一致性的核心算法。

ZAB 协议需要保证:

Note:

ZooKeeper 采用提案投票策略,并等待所有的 Follower 都返回确认信息,但,仍能保证所有的 Follower 上事务执行顺序跟 Leader 保持一致.

原因:Leader 跟 Follower 之间采用 TCP 长连接,广播的事务消息具有顺序性。

ZAB 协议用途

ZAB 协议应用场景:

ZAB 协议,规定:事务提交过程中,是 2PC

  1. 其只要求半数以上节点 ACK,就会提交事务;
  2. 没有要求所有的节点 ACK,因此,Leader 出现异常时,不同节点的数据不一致;
  3. ZAB 采用Leader 选举的崩溃恢复策略,保证新的 Leader 上数据是最新的数据即可;

ZAB 与 Paxos 算法的对比

ZAB 协议,并不是 Paxos 算法的一个典型实现。

两者的相同之处:

  1. Leader、Follower 角色:都存在类似 Leader 进程,负责协调多个 Follower 进程的运行;
  2. 投票机制:Leader 都会等待半数以上Follower 发出 ACK 后,才会提交事务;
  3. Leader 纪元:对 Leader 都存在一个唯一的 epoch 值;

两者很类似,本质区别:设计目标不一样

思考:what?啥区别?

补充:Paxos 的本质

Paxos 目标:解决分布式一致性问题,提高分布式系统容错性的一致性算法。

Paxos 本质:基于消息传递高度容错一致性算法

分布式系统的一致性问题:

  1. 消息传递:延迟性,先发送的消息,不一定先到达;
  2. 消息传递:丢失性,发送的消息,可能丢失;
  3. 节点崩溃:分布式系统内,任何一个节点都可能崩溃;

在这种情况下,如何保证数据的一致性?

  1. 提案投票:基于投票策略,2PC
  2. 选举投票:基于投票策略,投出优先级最高的节点(包含最新数据的节点)

参考资料

Top