Zookeeper 与 Kafka (2) : ZAB 协议

1. 分布式系统

  • 分布式系统的痛点
    • 在任何时间点, 如何判定那些服务器是存活的(alive) 和正在进行处理动作(operating)的 ?
    • 在面临各种错误和失败的情况下, 如何保证可靠性(reliably) ?
  • 分布式协调服务(Distributed Coordination Service)
    • 主要�应用于云计算场景中.
    • 为其它分布式应用提供关键的同步和分组服务.
  • 原子广播协议(Atomic broadcast protocol):
    • 主要的工作流程:
      • 选举 leader -> 同步各个 node -> leader 发起同步操作的广播.
    • 崩溃恢复: 能够从崩溃状态(crashed state)恢复为一个合法的状态.

2. ZAB 协议

2.1 崩溃可恢复的原子消息广播算法

  • 主备模式:
    • 集群中只有一个主进程来负责广播服务器的状态变更.
  • �有序的变更:
    • 保证全局的变更序列会被顺序应用, 解决变更间存在依赖的场景.

2.2 基本模式:

  1. 消息广播.
  • 工作流程(Proposal, Ack, Commit):
    1. Leader 将client 的请求转换为事务Proposal(含有ZXID字段), 并分发到所有的Followers.
    • Leader 等待Follows 的Ack.
    • 一旦半数的Follows 进行了正确的反馈, Leader 会向所有的Followers 分发commit, 同时要求其将前一个Proposal 提交.
  • ZAB 属于简化的二阶段提交协议.
    • 无法处理Leader崩溃而带来的数据不一致, 需要使用崩溃恢复来处理该场景.
  • 基于FIFO 特性的TCP 协议进行网络通信, 保证了消息接收和发送的顺序性.
    • Leader 会为每个Follower 分配单独的队列.
  • 崩溃恢复.
    • 确保已经在Leader 上提交的事务, 最终被所有服务器提交.
    • 确保丢弃只在Leader 上被proposal 的事务.
    • 保证新选举的Leader 拥有集群中最大ZXID 的事务Proposal, 则具有所有已经提交的Proposal.

2.3 崩溃恢复系统模型

  • 系统是由一系列的进程(peer) 组成的, 可被表示为: Π = {p1, p2, . . . , pN }. 进程间通过消息传递机制进行通信.
  • 仲裁(Quorum) 是系统的一个子集, 即Q ⊆ Π , 同时其满足条件: |Q| > N/2.
    • 也就是仲裁是含有系统一半以上�进程的节点集合.
  • 进程含有两种状态: Up 和 Down.
  • 进程对间的通信是双向的, 且满足了完整性(integrity)和前置性(prefix).
    • 所以使用具有FIFO 管道的TCP 协议 进行进程间的通信.
  • 每次状态改变(transaction) 都在前一个状态的基础上进行递增.
    • 由<v,z> 代表新状态, 其中z 是标示符, 用来对所有的transaction 进行排序.
    • 当需要更新新的primary 的状态时:
      • 找到所有进程中含有最大标示符的进程, 然后使用拷贝该进程中的transaction.
  • 进程(peer)
    • 状态: �Following, Leading, Election.

3. ZAB 协议的�阶段

  • Leader election(阶段0).
    • 进程将自己的投票(vote)保存在本地易失性存储器(local volatile memory)中.
    • 一个潜在的leader 会在阶段三变成事实上的leader.
    • 如果该peer 选举自己为leader, 那么将状态转换为leader.
  • Discovery(阶段1).
    • Followers 与它们选举的潜在leader 进行通信, 由leader 来收集当前的transactions.
    • 如果潜在的leader 并不处于leader 状态, 那么该进程会退回到阶段0.
  • Synchronisation(阶段2)
    • 使用leader 的更新历史来恢复和同步数据备份.
    • 工作过程: leader 对followers 发起transaction 请求; followers 如果发现自己当前落后于leader 的更新历史, 则恢复ACK; leader 紧接着发起提交(commit) 信息, 之后变成事实上的leader.
  • Broadcast(阶段3)
    • leader 对外通知, 说明其已经可以处理新的状态变更.
    • 如果没有崩溃发生, 则会一直处于当前状态(leader 不会变化).
  • 特性:
    • 阶段1,2,3 是异步的. 在followers 和leader 间使用周期性心跳消息来�检测错误, 如果发现心跳超时, 那么回退到阶段0.
  • 实现:
    • 快速leader 选取(Fast Leader Election(FLE)).
      • 尝试选举拥有最新历史(所有transaction已提交的) 的进程.
      • 这样将发现和同步过程合并为恢复过程.
    • peer 会交换各自的投票, 然后更新其选票为发现的拥有最新历史的peer.
    原文作者:沪上最强亚巴顿
    原文地址: https://www.jianshu.com/p/14c30466fba1
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞