【面试官】那ZooKeeper为什么还采用ZAB协议

面试官：听说你精通ZooKeeper，那我就考考你吧

面试官：不用慌尽管说，错了也没关系😊。。。

以贴近现实的【面试官面试】形式来分享技术，本期是《ZooKeeper系列》

面试官：知道ZAB协议吗

知道的，这个协议主要是两方面组成。

一个是消息广播、一个是崩溃恢复。

面试官思考中…

面试官：消息广播的二阶段提交你讲一讲

好的，消息广播使用的是原子广播协议，类似于二阶段提交过程。

他的流程是这样的，针对客户端的事务请求，Leader服务器会为其生成对应的事务Proposal，并发送给集群中其余机器，然后再分别收集各自的选票。

因为ZAB协议将二阶段提交中的事务中断逻辑移除，所以只需要收集过半Follower服务器的反馈Ack后即可，最后就是进行事务提交。

也就是分为二阶段，阶段一是询问事务的尝试能否成功，阶段二是事务提交。

面试官思考中…

面试官：那二阶段提交有什么缺点吗

hhh缺点挺多的。

1. 首先一个是同步阻塞问题。参与一个事务的其他逻辑都需要进行阻塞，等到上一个二阶段提交完成之后才会开始执行。
2. 在阶段二，如果只有部分Follow服务器没有收到事务提交的消息，会出现数据不一致的情况。
3. 另外还会出现单点问题。如果Leader服务器在阶段二奔溃了，那其他Follower服务器仍然会处理锁定事务资源的状态中。

面试官思考中…

面试官：既然怎么多缺点，ZooKeeper为什么还采用ZAB协议

首先一个是这个协议简单且实现方便，同时ZooKeeper还做了其他特殊处理。

1. 刚刚提到了ZAB协议取消了二阶段提交的事务中断逻辑，只需要半数服务器的投票数即可，这提高了工作效率
2. 另外ZAB协议添加了崩溃模式，解决了二阶段提交的各种问题

面试官思考中…

面试官：崩溃模式怎么解决这些问题的？

好的。它主要做了两个事情。

一个是确保提交已经被Leader提交的事务Proposal，另一个是丢弃已经被跳过的事务Proposal。

1. Leader服务器会为每一个Follower服务器都准备一个Proposal消息队列，通过该队列发送给那些没有被各Follower服务器同步的事务，同时在Proposal消息后面加上Commit消息。这可以解决二阶段提交带来的数据不一致问题。
2. ZooKeeper有一个高32位的epoch，用来作为Leader服务器的标识；有一个低32位的ZXID，用来作为最新已提交事务的偏移量。通过这两个标识来保证跳过丢弃的事务，这可以解决二阶段带来的单点问题。

面试官抓抓脑袋，继续看你的简历......

得想想考点你不懂的😰

未完待续。。。。。。

好了，今天的分享就先到这，我们下期【ZooKeeper系列】继续。

创作不易，不妨点赞、收藏、关注支持一下，各位的支持就是我创作的最大动力❤️