Zookeeper 与 Kafka (2) : ZAB 协议

1. 分布式系统

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

工作流程(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.

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

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.