有责任感的 zab

定义

Zookeeper Atomic Broadcast

Zookeeper 是通过 Zab 协议来保证分布式事务的最终一致性。

原因

Multi-Paxos 虽然能就一系列值达成共识，但不关心共识后的值是什么，同时它也不关心指令的顺序性。

而 zab 协议借鉴了 paxos，但是它是特别为Zookeeper设计的支持崩溃恢复的原子广播协议。

模型

zab 实现了一个主备的模型，只有一台 leader 负责处理外部的写事务请求，然后同步给其他 follower。

Zookeeper 客户端会随机的链接到 zookeeper 集群中的一个节点，如果是读请求，就直接从当前节点中读取数据；如果是写请求，那么节点就会向 Leader 提交事务，Leader 接收到事务提交，会广播该事务，只要超过半数节点写入成功，该事务就会被提交。

要点

消息广播

基本过程

1. leader 收到消息
2. leader 广播消息
3. leader 收到大多数 follower 的确认
4. leader 向所有 follower 广播 commit 消息，同时自身也会完成事务提交
5. follower 收到 commit 并自己 commit

细节点

• 每个事务都有一个全局递增的唯一 ID，ZXID，zab需要保证执行顺序，每个事务必须按 ZXID 排序后处理
• leader 和 每一个 follower 之间都有一个 FIFO queue，除了解耦之外，同时也一定程度的保证了事务的执行顺序

崩溃恢复

原则

• ZAB 协议确保那些已经在 Leader 提交的事务最终会被所有服务器提交。
• ZAB 协议确保丢弃那些只在 Leader 提出/复制，但没有提交的事务。

实现方式

1. 崩溃后进行选举
2. 根据 ZXID 选举 leader，ZXID 最大，同时新选举出来的 Leader 不能包含未提交的 Proposal
3. 选举成功开始同步数据
4. leader 确认事务是否已经被过半的 follower 提交，进行数据同步，保证数据一致
5. 等到 Follower 将所有尚未同步的事务 Proposal 都从 Leader 服务器上同步过来并且应用到内存数据中以后，Leader 才会把该 Follower 加入到真正可用的 Follower 列表中
6. 进入消息广播模式

ZXID

一共 64 位，高 32 位代表了每代 Leader 的唯一性，低 32 代表了每代 Leader 中事务的唯一性。

总结

• 为什么说 zab 有责任感呢？因为他和别人不要的地方再，如果有消息被提交了，那么就不会忘记了。

• 为了实现这个目标，它做了什么保证措施呢？

1. 选举的时候保证，保证了 ZXID 最大（其实这个和 raft 类似，就是指向了日志最多的人）
2. 利用队列保证，消息来的时候都通过了队列，所以一定程度也保证了先来先处理

• 消息广播就是一个 2PC 只不过奔溃恢复解决了 2PC 的单点问题
• 本质还是一个主备，压力还是在主节点上哦