2021-Java后端工程师面试指南-(分布式理论+Zookeeper）

最新推荐文章于 2024-11-09 13:22:22 发布

六脉神剑1

最新推荐文章于 2024-11-09 13:22:22 发布

阅读量1.5k

点赞数 6

文章标签：分布式 zookeeper java 数据库面试

本文链接：https://blog.csdn.net/qq_42820805/article/details/114275258

版权

前言

文本已收录至我的GitHub仓库，欢迎Star：https://github.com/bin392328206/six-finger
种一棵树最好的时间是十年前，其次是现在

Tips

面试指南系列，很多情况下不会去深挖细节，是小六六以被面试者的角色去回顾知识的一种方式，所以我默认大部分的东西，作为面试官的你，肯定是懂的。

https://www.processon.com/view/link/600ed9e9637689349038b0e4

上面的是脑图地址

叨絮

分布式系统开发,我们当然是需要了解分布式系统的一些理论知识拉，今天就来看看这些理论吧

然后下面是前面的文章汇总

2021-Java后端工程师面试指南-(引言)
2021-Java后端工程师面试指南-(Java基础篇）
2021-Java后端工程师面试指南-(并发-多线程)
2021-Java后端工程师面试指南-(JVM）
2021-Java后端工程师面试指南-(MySQL）
2021-Java后端工程师面试指南-(Redis）
2021-Java后端工程师面试指南-(Elasticsearch）
2021-Java后端工程师面试指南-(消息队列）
2021-Java后端工程师面试指南-(SSM）
2021-Java后端工程师面试指南-(SpringBoot+SpringCloud）

然后再来看看ZK。

了解分布式的CAP理论吗？聊聊呗

CAP 也就是 Consistency（一致性）、Availability（可用性）、Partition Tolerance（分区容错性）这三个单词首字母组合。

在理论计算机科学中，CAP 定理（CAP theorem）指出对于一个分布式系统来说，当设计读写操作时，只能能同时满足以下三点中的两个：

一致性（Consistence） : 所有节点访问同一份最新的数据副本
可用性（Availability）: 非故障的节点在合理的时间内返回合理的响应（不是错误或者超时的响应）。
分区容错性（Partition tolerance） : 分布式系统出现网络分区的时候，仍然能够对外提供服务。

并且网络是不靠谱的，所以我们必须要满足分区容错性，所以在分布式理论上不可能选择 CA 架构，只能选择 CP 或者 AP 架构。

举个例子来说说CAP 实际应用案例呗

ZooKeeper 保证的是 CP。任何时刻对 ZooKeeper 的读请求都能得到一致性的结果，但是， ZooKeeper 不保证每次请求的可用性比如在 Leader 选举过程中或者半数以上的机器不可用的时候服务就是不可用的。
Eureka 保证的则是 AP。Eureka 在设计的时候就是优先保证 A （可用性）。在 Eureka 中不存在什么 Leader 节点，每个节点都是一样的、平等的。因此 Eureka 不会像 ZooKeeper 那样出现选举过程中或者半数以上的机器不可用的时候服务就是不可用的情况。Eureka 保证即使大部分节点挂掉也不会影响正常提供服务，只要有一个节点是可用的就行了。只不过这个节点上的数据可能并不是最新的。
Nacos 不仅支持 CP 也支持 AP。

了解Base理论嘛，说说Base理论吧

BASE 是 Basically Available（基本可用）、Soft-state（软状态）和 Eventually Consistent（最终一致性）三个短语的缩写。BASE 理论是对 CAP 中一致性 C 和可用性 A 权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于 CAP 定理逐步演化而来的，它大大降低了我们对系统的要求。

BASE 理论的核心思想即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

BASE 理论本质上是对 CAP 的延伸和补充，更具体地说，是对 CAP 中 AP 方案的一个补充。

聊聊Paxos一致性协议呗

Paxos问题指分布式系统中存在故障fault，但不存在恶意corrupt节点场景（消息可能丢失但不会造假）下的共识达成（Consensus）问题。

Paxos是第一个被证明的共识算法，原理基于两阶段提交并进行扩展。算法中将节点分为三种类型：

倡议者proposer：提交一个提案，等待大家批准为结案，往往是客户端担任。
接受者acceptor：负责对提案进行投票，往往服务器担任。提议超过半数的接受者投票及被选中。
学习者learner：被告知提案结果，并与之统一，不参与投票过程。客户端和服务端都可担任。

每个节点在协议中可以担任多个角色。

Paxos的特点：

一个或多个节点可以提出提议
系统针对所有提案中的某个提案必须达成一致
最多只能对一个确定的提案达成一致
只要超过半数的节点存活且可互相通信，整个系统一定能达成一致状态

总结Paxos两阶段提交

两个阶段分别是准备（prepare）和提交（commit）。准备阶段解决大家对哪个提案进行投票的问题，提交阶段解决确认最终值的问题。

简单来说，提案者发出提案后，收到一些反馈，有两种结果，一种结果是自己的提案被大多数节点接受了，另外一种是没被接受，没被接受就过会再试试。提案者收到来自大多数的接受反馈，也不能认为这就是最终确认。因为这些接收者并不知道自己刚反馈的提案就是全局的绝对大多数。所以，引入新的一轮再确认阶段是必须的，提案者在判断这个提案可能被大多数接受的情况下，发起一轮新的确认提案。这就进入了提交阶段。提交阶段的提案发送出去，其他阶段进行提案值比较，返回最大的，所以提案者收到返回消息不带新的提案，说明锁定成功，如果有新的提案内容，进行提案值最大比较，然后替换更大的值。如果没有收到足够多的回复，则需要再次发出请求。

一旦多数接受了共同的提案值，则形成决议，称为最终确认的提案。

两个阶段分别是准备（prepare）和提交（commit）。准备阶段解决大家对哪个提案进行投票的问题，提交阶段解决确认最终值的问题。

简单来说，提案者发出提案后，收到一些反馈，有两种结果，一种结果是自己的提案被大多数节点接受了，另外一种是没被接受，没被接受就过会再试试。
提案者收到来自大多数的接受反馈，也不能认为这就是最终确认。因为这些接收者并不知道自己刚反馈的提案就是全局的绝对大多数。所以，引入新的一轮再确认阶段是必须的，提案者在判断这个提案可能被大多数接受的情况下，发起一轮新的确认提案。这就进入了提交阶段。提交阶段的提案发送出去，其他阶段进行提案值比较，返回最大的，所以提案者收到返回消息不带新的提案，说明锁定成功，如果有新的提案内容，进行提案值最大比较，然后替换更大的值。如果没有收到足够多的回复，则需要再次发出请求。
一旦多数接受了共同的提案值，则形成决议，称为最终确认的提案。

那我们来聊聊Raft算法

Raft 算法也是一种少数服从多数的算法，在任何时候一个服务器可以扮演以下角色之一：

Leader：负责 Client 交互和 log 复制，同一时刻系统中最多存在一个
Follower：被动响应请求 RPC，从不主动发起请求 RPC
Candidate : 由Follower 向Leader转换的中间状态

Term 在Raft中使用了一个可以理解为周期（第几届、任期）的概念，用Term作为一个周期，每个Term都是一个连续递增的编号，每一轮选举都是一个Term周期，在一个Term中只能产生一个Leader；先简单描述下Term的变化流程：Raft开始时所有Follower的Term为1，其中一个Follower逻辑时钟到期后转换为Candidate，Term加1，这时Term为2（任期），然后开始选举，这时候有几种情况会使Term发生改变：

如果当前Term为2的任期内没有选举出Leader或出现异常，则Term递增，开始新一任期选举
当这轮Term为2的周期选举出Leader后，过后Leader宕掉了，然后其他Follower转为Candidate，Term递增，开始新一任期选举
当Leader或Candidate发现自己的Term比别的Follower小时，Leader或Candidate将转为Follower，Term递增
当Follower的Term比别的Term小时，Follower也将更新Term保持与其他Follower一致；
可以说每次Term的递增都将发生新一轮的选举，Raft保证一个Term只有一个Leader，在Raft正常运转中所有的节点的Term都是一致的，如果节点不发生故障一个Term（任期）会一直保持下去，当某节点收到的请求中Term比当前Term小时则拒绝该请求；

选举 Raft的选举由定时器来触发，每个节点的选举定时器时间都是不一样的，开始时状态都为Follower，某个节点定时器触发选举后Term递增，状态由Follower转为Candidate，向其他节点发起RequestVote RPC请求，这时候有三种可能的情况发生：

该RequestVote请求接收到n/2+1（过半数）个节点的投票，从Candidate转为Leader，向其他节点发送heartBeat以保持Leader的正常运转
在此期间如果收到其他节点发送过来的AppendEntries RPC请求，如该节点的Term大则当前节点转为Follower，否则保持Candidate拒绝该请求
Election timeout发生则Term递增，重新发起选举

在一个Term期间每个节点只能投票一次，所以当有多个Candidate存在时就会出现每个Candidate发起的选举都存在接收到的投票数都不过半的问题，这时每个Candidate都将Term递增、重启定时器并重新发起选举，由于每个节点中定时器的时间都是随机的，所以就不会多次存在有多个Candidate同时发起投票的问题。

聊聊paxos 算法与 raft 算法的差异

相同点

得到大多数的赞成，这个 entries 就会定下来，最终所有节点都会赞成不同点
raft强调是唯一leader的协议，此leader至高无上raft：新选举出来的leader拥有全部提交的日志，而 paxos 需要额外的流程从其他节点获取已经被提交的日志，它允许日志有空洞

聊聊Zookeeper吧

Zookeeper是一个开源的分布式的，为分布式应用提供协调服务的Apache项目。Zookeeper从设计模式角度来理解：是一个基于观察者模式设计的分布式服务管理框架，它负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，Zookeeper就将负责通知已经在Zookeeper上注册的那些观察者做出相应的反应，从而实现集群中类似Master/Slave管理模式

Zookeeper：一个领导者（leader），多个跟随者（follower）组成的集群。
Leader负责进行投票的发起和决议，更新系统状态
Follower用于接收客户请求并向客户端返回结果，在选举Leader过程中参与投票
集群中只要有半数以上节点存活，Zookeeper集群就能正常服务。
全局数据一致：每个server保存一份相同的数据副本，client无论连接到哪个server，数据都是一致的。
更新请求顺序进行，来自同一个client的更新请求按其发送顺序依次执行。
数据更新原子性，一次数据更新要么成功，要么失败。
实时性，在一定时间范围内，client能读到最新数据。

ZooKeeper数据模型的结构与Unix文件系统很类似，整体上可以看作是一棵树，每个节点称做一个ZNode。很显然zookeeper集群自身维护了一套数据结构。这个存储结构是一个树形结构，其上的每一个节点，我们称之为"znode"，每一个znode默认能够存储1MB的数据，每个ZNode都可以通过其路径唯一标识

说说Zookeeper的事件通知机制吧

我们可以把 Watch 理解成是注册在特定 Znode 上的触发器。当这个 Znode 发生改变，也就是调用了 create，delete，setData 方法的时候，将会触发 Znode 上注册的对应事件，请求 Watch 的客户端会接收到异步通知。

具体交互过程如下：

客户端调用 getData 方法，watch 参数是 true。服务端接到请求，返回节点数据，并且在对应的哈希表里插入被 Watch 的 Znode 路径，以及 Watcher 列表。
当被 Watch 的 Znode 已删除，服务端会查找哈希表，找到该 Znode 对应的所有 Watcher，异步通知客户端，并且删除哈希表中对应的 Key-Value。

说说Zookeeper的ZAB协议

Zookeeper Atomic Broadcast，有效解决了 Zookeeper 集群崩溃恢复，以及主从同步数据的问题。

Zookeeper集群的节点状态

Looking ：选举状态。
Following ：Follower 节点（从节点）所处的状态。
Leading ：Leader 节点（主节点）所处状态。

最大事务id 最大 ZXID 也就是节点本地的最新事务编号，包含 epoch 和计数两部分。epoch 是纪元的意思，相当于 Raft 算法选主时候的 term。

说说ZAB协议的崩溃恢复，也就是master选举

假如 Zookeeper 当前的主节点挂掉了，集群会进行崩溃恢复。ZAB 的崩溃恢复分成三个阶段：

选举阶段，此时集群中的节点处于 Looking 状态。它们会各自向其他节点发起投票，投票当中包含自己的服务器 ID 和最新事务 ID（ZXID）。接下来，节点会用自身的 ZXID 和从其他节点接收到的 ZXID 做比较，如果发现别人家的 ZXID 比自己大，也就是数据比自己新，那么就重新发起投票，投票给目前已知最大的 ZXID 所属节点。每次投票后，服务器都会统计投票数量，判断是否有某个节点得到半数以上的投票。如果存在这样的节点，该节点将会成为准 Leader，状态变为 Leading。其他节点的状态变为 Following。
发现阶段，用于在从节点中发现最新的 ZXID 和事务日志。或许有人会问：既然 Leader 被选为主节点，已经是集群里数据最新的了，为什么还要从节点中寻找最新事务呢？这是为了防止某些意外情况，比如因网络原因在上一阶段产生多个 Leader 的情况。所以这一阶段，Leader 集思广益，接收所有 Follower 发来各自的最新 epoch 值。Leader 从中选出最大的 epoch，基于此值加 1，生成新的 epoch 分发给各个 Follower。
同步阶段同步阶段，把 Leader 刚才收集得到的最新历史事务日志，同步给集群中所有的 Follower。只有当半数 Follower 同步成功，这个准 Leader 才能成为正式的 Leader。