前言:七月末八月初的时候,秋招正式打响,公司会放出大量的全职和实习岗位。为了帮助秋招的小伙伴们,学长这里整理了一系列的秋招面试题给大家,所以小伙伴们不用太过焦虑,相信你们一定能超常发挥,收到心仪公司的Offer~~
内容涵盖:Java、MyBatis、ZooKeeper、Dubbo、Elasticsearch、Memcached、Redis、MySQL、Spring、Spring Boot、Spring Cloud、RabbitMQ、Kafka、Linux等技术栈
编辑
目录
ZooKeeper面试题
13.服务器角色
Leader
1、事务请求的唯一调度和处理者,保证集群事务处理的顺序性2、集群内部各服务的调度者
Follower
1、处理客户端的非事务请求,转发事务请求给 Leader服务器2、参与事务请求 Proposal的投票
3、参与 Leader选举投票
Observer
1、3.0版本以后引入的一个服务器角色,在不影响集群事务处理能力的基础上提升集群的非事务处理能力
2、处理客户端的非事务请求,转发事务请求给 Leader服务器
3、不参与任何形式的投票
14. Zookeeper下 Server工作状态
服务器具有四种状态,分别是 LOOKING、FOLLOWING、LEADING、OBSERVING。
1、LOOKING:寻找 Leader状态。当服务器处于该状态时,它会认为当前集群中没有 Leader,因此需要进入 Leader选举状态。
2、FOLLOWING:跟随者状态。表明当前服务器角色是 Follower。
3、LEADING:领导者状态。表明当前服务器角色是 Leader。
4、OBSERVING:观察者状态。表明当前服务器角色是 Observer。
15.数据同步
整个集群完成 Leader选举之后,Learner(Follower和 Observer的统称)回向Leader服务器进行注册。当 Learner服务器想 Leader服务器完成注册后,进入数据同步环节。
数据同步流程:(均以消息传递的方式进行)
Learner向 Learder注册
数据同步
同步确认
Zookeeper的数据同步通常分为四类:
1、直接差异化同步(DIFF同步)
2、先回滚再差异化同步(TRUNC+DIFF同步)
3、仅回滚同步(TRUNC同步)
4、全量同步(SNAP同步)
在进行数据同步前,Leader服务器会完成数据同步初始化:
peerLastZxid:
从 learner服务器注册时发送的 ACKEPOCH消息中提取 lastZxid(该
Learner服务器最后处理的 ZXID)
minCommittedLog:
Leader服务器 Proposal缓存队列 committedLog中最小 ZXID
maxCommittedLog:
Leader服务器 Proposal缓存队列 committedLog中最大 ZXID
直接差异化同步(DIFF同步)
场景:peerLastZxid介于 minCommittedLog和 maxCommittedLog
之间
先回滚再差异化同步(TRUNC+DIFF同步)
场景:当新的 Leader服务器发现某个 Learner服务器包含了一条自己没
有的事务记录,那么就需要让该 Learner服务器进行事务回滚--回滚到 Leader服务器上存在的,同时也是最接近于 peerLastZxid的 ZXID
仅回滚同步(TRUNC同步)
场景:peerLastZxid大于 maxCommittedLog
全量同步(SNAP同步)
场景一:peerLastZxid小于 minCommittedLog
场景二:Leader服务器上没有 Proposal缓存队列且 peerLastZxid不等
于 lastProcessZxid
16. zookeeper是如何保证事务的顺序一致性的?
zookeeper采用了全局递增的事务 Id来标识,所有的 proposal(提议)都在被提出的时候加上了 zxid,zxid实际上是一个 64位的数字,高 32位是 epoch(时期;纪元;世;新时代)用来标识 leader周期,如果有新的 leader产生出来,epoch会自增,低 32位用来递增计数。当新产生 proposal的时候,会依据数据库的两阶段过程,首先会向其他的 server发出事务执行请求,如果超过半数的机器都能执行并且能够成功,那么就会开始执行。
17.分布式集群中为什么会有 Master?
在分布式环境中,有些业务逻辑只需要集群中的某一台机器进行执行,其他的机器可以共享这个结果,这样可以大大减少重复计算,提高性能,于是就需要进行leader选举。
本期分享到此为止,关注博主不迷路,叶秋学长带你上高速~~