面试官：听说你精通ZooKeeper，那我就考考你吧
面试官：不用慌尽管说，错了也没关系😊。。。
以贴近现实的【面试官面试】形式来分享技术，本期是《ZooKeeper系列》，感兴趣就关注我吧❤️
面试官：知道ZAB协议吗
知道的，这个协议主要是两方面组成。
一个是消息广播、一个是崩溃恢复。
面试官思考中…
面试官：消息广播的二阶段提交你讲一讲
好的，消息广播使用的是原子广播协议，类似于二阶段提交过程。
他的流程是这样的，针对客户端的事务请求，Leader服务器会为其生成对应的事务Proposal，并发送给集群中其余机器，然后再分别收集各自的选票。
因为ZAB协议将二阶段提交中的事务中断逻辑移除，所以只需要收集过半Follower服务器的反馈Ack后即可，最后就是进行事务提交。
也就是分为二阶段，阶段一是询问事务的尝试能否成功，阶段二是事务提交。
面试官思考中…
面试官：那二阶段提交有什么缺点吗
hhh缺点挺多的。
- 首先一个是同步阻塞问题。参与一个事务的其他逻辑都需要进行阻塞，等到上一个二阶段提交完成之后才会开始执行。
- 在阶段二，如果只有部分Follow服务器没有收到事务提交的消息，会出现数据不一致的情况。
- 另外还会出现单点问题。如果Leader服务器在阶段二奔溃了，那其他Follower服务器仍然会处理锁定事务资源的状态中。
面试官思考中…
面试官：既然怎么多缺点，ZooKeeper为什么还采用ZAB协议
首先一个是这个协议简单且实现方便，同时ZooKeeper还做了其他特殊处理。
- 刚刚提到了ZAB协议取消了二阶段提交的事务中断逻辑，只需要半数服务器的投票数即可，这提高了工作效率
- 另外ZAB协议添加了崩溃模式，解决了二阶段提交的各种问题
面试官思考中…
面试官：那崩溃模式怎么解决这些问题的？
好的。它主要做了两个事情。
一个是确保提交已经被Leader提交的事务Proposal，另一个是丢弃已经被跳过的事务Proposal。
- Leader服务器会为每一个Follower服务器都准备一个Proposal消息队列，通过该队列发送给那些没有被各Follower服务器同步的事务，同时在Proposal消息后面加上Commit消息。这可以解决二阶段提交带来的数据不一致问题。
- ZooKeeper有一个高32位的epoch，用来作为Leader服务器的标识；有一个低32位的ZXID，用来作为最新已提交事务的偏移量。通过这两个标识来保证跳过丢弃的事务，这可以解决二阶段带来的单点问题。
面试官：对了，你刚刚提到的事务中断逻辑是什么
是二阶段提交的一个过程，不过被ZAB协议移除了。
在阶段一，只要有一个Follower服务器返回事务尝试失败，或响应超时，那本次事务就会中断。
Leader服务器会通知其他Follower服务器，回滚本次的事务。
面试官抓抓脑袋，继续看你的简历......
得想想考点你不懂的😰
未完待续。。。。。。
好了，今天的分享就先到这，我们下期【ZooKeeper系列】继续。
创作不易，不妨点赞、收藏、关注支持一下，各位的支持就是我创作的最大动力❤️
