定义
Zookeeper Atomic Broadcast
Zookeeper 是通过 Zab 协议来保证分布式事务的最终一致性。
原因
Multi-Paxos 虽然能就一系列值达成共识，但不关心共识后的值是什么，同时它也不关心指令的顺序性。
而 zab 协议借鉴了 paxos，但是它是特别为Zookeeper设计的支持崩溃恢复的原子广播协议。
模型
zab 实现了一个主备的模型，只有一台 leader 负责处理外部的写事务请求，然后同步给其他 follower。
Zookeeper 客户端会随机的链接到 zookeeper 集群中的一个节点，如果是读请求，就直接从当前节点中读取数据；如果是写请求，那么节点就会向 Leader 提交事务，Leader 接收到事务提交，会广播该事务，只要超过半数节点写入成功，该事务就会被提交。
要点
消息广播
基本过程
- leader 收到消息
- leader 广播消息
- leader 收到大多数 follower 的确认
- leader 向所有 follower 广播 commit 消息，同时自身也会完成事务提交
- follower 收到 commit 并自己 commit
细节点
- 每个事务都有一个全局递增的唯一 ID，ZXID，zab需要保证执行顺序，每个事务必须按 ZXID 排序后处理
- leader 和 每一个 follower 之间都有一个 FIFO queue，除了解耦之外，同时也一定程度的保证了事务的执行顺序
崩溃恢复
原则
- ZAB 协议确保那些已经在 Leader 提交的事务最终会被所有服务器提交。
- ZAB 协议确保丢弃那些只在 Leader 提出/复制，但没有提交的事务。
实现方式
- 崩溃后进行选举
- 根据 ZXID 选举 leader，ZXID 最大，同时新选举出来的 Leader 不能包含未提交的 Proposal
- 选举成功开始同步数据
- leader 确认事务是否已经被过半的 follower 提交，进行数据同步，保证数据一致
- 等到 Follower 将所有尚未同步的事务 Proposal 都从 Leader 服务器上同步过来并且应用到内存数据中以后，Leader 才会把该 Follower 加入到真正可用的 Follower 列表中
- 进入消息广播模式
ZXID
一共 64 位，高 32 位代表了每代 Leader 的唯一性，低 32 代表了每代 Leader 中事务的唯一性。
总结
为什么说 zab 有责任感呢？因为他和别人不要的地方再，如果有消息被提交了，那么就不会忘记了。
为了实现这个目标，它做了什么保证措施呢？
- 选举的时候保证，保证了 ZXID 最大（其实这个和 raft 类似，就是指向了日志最多的人）
- 利用队列保证，消息来的时候都通过了队列，所以一定程度也保证了先来先处理
- 消息广播就是一个 2PC 只不过奔溃恢复解决了 2PC 的单点问题
- 本质还是一个主备，压力还是在主节点上哦
