[Java后端技术]23个带答案的Zookeeper经典面试题!( 三 )


2)写任意(WriteAny):对数据的修改可提交给任意的节点 , 跟读一样 。 这种情况下 , 客户端对集群节点的角色与变化透明 。
对zookeeper来说 , 它采用的方式是写任意 。 通过增加机器 , 它的读吞吐能力和响应能力扩展性非常好 , 而写 , 随着机器的增多吞吐能力肯定下降(这也是它建立observer的原因) , 而响应能力则取决于具体实现方式 , 是延迟复制保持最终一致性 , 还是立即复制快速响应 。
14、Zookeeper工作原理
Zookeeper的核心是原子广播 , 这个机制保证了各个Server之间的同步 。 实现这个机制的协议叫做Zab协议 。 Zab协议有两种模式 , 它们分别是恢复模式(选主)和广播模式(同步) 。 当服务启动或者在领导者崩溃后 , Zab就进入了恢复模式 , 当领导者被选举出来 , 且大多数Server完成了和leader的状态同步以后 , 恢复模式就结束了 。 状态同步保证了leader和Server具有相同的系统状态 。
15、zookeeper是如何保证事务的顺序一致性的?
zookeeper采用了递增的事务Id来标识 , 所有的proposal(提议)都在被提出的时候加上了zxid , zxid实际上是一个64位的数字 , 高32位是epoch(时期;纪元;世;新时代)用来标识leader是否发生改变 , 如果有新的leader产生出来 , epoch会自增 , 低32位用来递增计数 。 当新产生proposal的时候 , 会依据数据库的两阶段过程 , 首先会向其他的server发出事务执行请求 , 如果超过半数的机器都能执行并且能够成功 , 那么就会开始执行 。
16、Zookeeper下Server工作状态
每个Server在工作过程中有三种状态:
LOOKING:当前Server不知道leader是谁 , 正在搜寻
LEADING:当前Server即为选举出来的leader
FOLLOWING:leader已经选举出来 , 当前Server与之同步
17、zookeeper是如何选取主leader的?
当leader崩溃或者leader失去大多数的follower , 这时zk进入恢复模式 , 恢复模式需要重新选举出一个新的leader , 让所有的Server都恢复到一个正确的状态 。 Zk的选举算法有两种:一种是基于basicpaxos实现的 , 另外一种是基于fastpaxos算法实现的 。 系统默认的选举算法为fastpaxos 。
Zookeeper选主流程(basicpaxos)
(1)选举线程由当前Server发起选举的线程担任 , 其主要功能是对投票结果进行统计 , 并选出推荐的Server;
(2)选举线程首先向所有Server发起一次询问(包括自己);
(3)选举线程收到回复后 , 验证是否是自己发起的询问(验证zxid是否一致) , 然后获取对方的id(myid) , 并存储到当前询问对象列表中 , 最后获取对方提议的leader相关信息(id,zxid) , 并将这些信息存储到当次选举的投票记录表中;
(4)收到所有Server回复以后 , 就计算出zxid最大的那个Server , 并将这个Server相关信息设置成下一次要投票的Server;
(5)线程将当前zxid最大的Server设置为当前Server要推荐的Leader , 如果此时获胜的Server获得n/2+1的Server票数 , 设置当前推荐的leader为获胜的Server , 将根据获胜的Server相关信息设置自己的状态 , 否则 , 继续这个过程 , 直到leader被选举出来 。 通过流程分析我们可以得出:要使Leader获得多数Server的支持 , 则Server总数必须是奇数2n+1 , 且存活的Server的数目不得少于n+1.每个Server启动后都会重复以上流程 。 在恢复模式下 , 如果是刚从崩溃状态恢复的或者刚启动的server还会从磁盘快照中恢复数据和会话信息 , zk会记录事务日志并定期进行快照 , 方便在恢复时进行状态恢复 。
[Java后端技术]23个带答案的Zookeeper经典面试题!
文章图片
Zookeeper选主流程(basicpaxos)fastpaxos流程是在选举过程中 , 某Server首先向所有Server提议自己要成为leader , 当其它Server收到提议以后 , 解决epoch和zxid的冲突 , 并接受对方的提议 , 然后向对方发送接受提议完成的消息 , 重复这个流程 , 最后一定能选举出Leader 。


推荐阅读