zab协议 小结

日常学习小结，不计格式，不计内容，只做笔记之用！！！

一、是什么
zab协议（zookeeper原子广播协议，支持崩溃恢复原子广播协议），Zookeeper 是通过 Zab 协议来保证分布式事务的最终一致性，主备模型（leader、follower）

二、特性
1) Zab 协议需要确保那些已经在 Leader 服务器上提交（Commit）的事务最终被所有的服务器提交。
2) Zab 协议需要确保丢弃那些只在 Leader 上被提出而没有被提交的事务

 总结一点：保证leader、follower上数据一致

三、作用
1) leader （唯一写操作进程）接收并处理写请求，并采用原子广播，将数据同步到各follower节点上。
2) 全局时钟
3) leader宕机或网络异常时，集群会重新选举leader，不会影响工作

 注：在整个消息广播中，Leader会将每一个事务请求转换成对应的 proposal 来进行广播，并且在广播 事务Proposal 之前，Leader服务器会首先为这个事务Proposal分配一个全局单递增的唯一ID，称之为事务ID（即zxid），由于Zab协议需要保证每一个消息的严格的顺序关系，因此必须将每一个proposal按照其zxid的先后顺序进行排序和处理。

四、原理（阶段）
1) 发现 产生一个leader
2) 同步 leader将本身数据同步到follower上，做到多副本存储，符合cap理论的分区容错和高可用性
3) 广播 leader接收到事务Proposal时，会将事务Proposal广播给所有的follower

五、内容
1) 崩溃恢复
a) 当zookeeper集群刚启动或者重新选举zookeeper是，集群进入恢复模式。
b) 当产生出新的leader，与半数以上的follower完成数据同步，集群退出恢复模式，进入消息广播模式。
c) 当有新的符合zab协议的节点加入集群，此节点进入恢复模式，找到leader进行数据同步。
d) 当leader出现宕机或者半数follower未能响应其广播的事务Proposal时，集群再次进入恢复模式。
2) 消息广播
类似于2PC提交（事务预提交阶段、提交阶段），不同的是，2PC提交需要所有的所有节点响应XA（事务管理器），不然就会进入等待，但zab协议只要有半数节点响应，事务就会进行提交。
步骤：a) 客户端发起一个写操作请求。
b) Leader 服务器将客户端的请求转化为事务 Proposal 提案，同时为每个 Proposal 分配一个全局的ID，即zxid。
c) Leader 服务器为每个 Follower 服务器分配一个单独的队列，然后将需要广播的 Proposal 依次放到队列中取，并且根据 FIFO 策略进行消息发送。
d) Follower 接收到 Proposal 后，会首先将其以事务日志的方式写入本地磁盘中，写入成功后向 Leader 反馈一个 Ack 响应消息。
e) Leader 接收到超过半数以上 Follower 的 Ack 响应消息后，即认为消息发送成功，可以发送 commit 消息。
f) Leader 向所有 Follower 广播 commit 消息，同时自身也会完成事务提交。Follower 接收到 commit 消息后，会将上一条事务提交。
注：zookeeper 采用 Zab 协议的核心，就是只要有一台服务器提交了 Proposal，就要确保所有的服务器最终都能正确提交 Proposal。这也是 CAP/BASE 实现最终一致性的一个体现。

Leader 服务器与每一个 Follower 服务器之间都维护了一个单独的 FIFO 消息队列进行收发消息，使用队列消息可以做到异步解耦。 Leader 和 Follower 之间只需要往队列中发消息即可。如果使用同步的方式会引起阻塞，性能要下降很多。

六、运用场景
1) Master选举
要点：抢占临时节点 + 监听器
2) 服务注册与发现
要点：临时节点 + 监听器
3) 分布式锁
要点：临时顺序节点 + 监听器
4) 配置中心
要点：持久节点 + 监听器

附：