最后
我还通过一些渠道整理了一些大厂真实面试主要有:蚂蚁金服、拼多多、阿里云、百度、唯品会、携程、丰巢科技、乐信、软通动力、OPPO、银盛支付、中国平安等初,中级,高级Java面试题集合,附带超详细答案,希望能帮助到大家。
还有专门针对JVM、SPringBoot、SpringCloud、数据库、Linux、缓存、消息中间件、源码等相关面试题。
1. Quorum 定义
Quorum 的定义如下——
假设有 N 个副本,更新操作 wi 在 W 个副本中更新成功之后,才认为此次更新操作 wi 成功,把这次成功提交的更新操作对应的数据叫作“成功提交的数据”。
对于读操作而言,至少需要读 R 个副本才能读到此次更新的数据,其中,W+R>N ,即 W 和 R 有重叠,一般,W+R=N+1。
-
N = 存储数据副本的数量
-
W = 更新成功所需的副本
-
R = 一次数据对象读取要访问的副本的数量
Quorum 就是限定了一次需要读取至少 N+1-W 的副本数据。
举个例子,我们维护了 10 个副本,一次成功更新了 3 个,那么至少需要读取 8 个副本的数据,可以保证我们读到最新的数据。
2. Quorum 的应用
Quorum 机制无法保证强一致性,也就是无法实现任何时刻任何用户或节点都可以读到最近一次成功提交的副本数据。
需要配合一个获取最新成功提交的版本号的 metadata 服务,这样可以确定最新已经成功提交的版本号,然后从已经读到的数据中就可以确认最新写入的数据。
Quorum 是分布式系统中常用的一种机制,用来保证数据冗余和最终一致性的投票算法,在 Paxos、Raft 和 ZooKeeper 的 Zab 等算法中,都可以看到 Quorum 机制的应用。
Paxos
1. Paxos 的节点角色
在 Paxos 协议中,有三类节点角色,分别是 Proposer
、Acceptor
和 Learner
,另外还有一个 Client
作为产生议题者。
上述三类角色只是逻辑上的划分,在工作实践中,一个节点可以同时充当这三类角色。
- Proposer 提案者
在流程开始时,Proposer 提出议案,也就是 value。在工程中 value 可以是任何操作,比如“修改某个变量的值为某个新值”。
Proposer 可以有多个,不同的 Proposer 可以提出不同的甚至矛盾的 value,比如某个 Proposer 提议“将变量 X
设置为 1
”,另一个 Proposer 提议“将变量 X
设置为 2
”,但对同一轮 Paxos 过程,最多只有一个 value 被批准。
- Acceptor 批准者
在集群中,Acceptor 有 N 个,Acceptor 之间完全对等独立,Proposer 提出的 value 必须获得超过半数(N/2+1)的 Acceptor 批准后才能通过。
- Learner 学习者
Learner 不参与选举,而是学习被批准的 value,在 Paxos 中,Learner 主要参与相关的状态机同步流程。
这里 Leaner 的流程就参考了 Quorum 议会机制,某个 value 需要获得 W=N/2+1 的 Acceptor 批准,Learner 需要至少读取 N/2+1 个 Accpetor,最多读取 N 个 Acceptor 的结果后,才能学习到一个通过的 value。
- Client 产生议题者
Client 作为产生议题者,实际不参与选举过程,比如发起修改请求的来源等。
2. Proposer 与 Acceptor 之间的交互
Paxos 中,Proposer 和 Acceptor 是算法核心角色。Paxos 描述的就是在一个由多个 Proposer 和多个 Acceptor 构成的系统中,如何让多个 Acceptor 针对 Proposer 提出的多种提案达成一致的过程,而 Learner 只是“学习”最终被批准的提案。
Proposer 与 Acceptor 之间的交互主要有 4 类消息通信,对应 Paxos 算法的两个阶段 4 个过程。
3. Paxos 选举过程
选举过程可以分为两个部分,准备阶段和选举阶段,可以查看下面的时序图:
3.1 Phase 1 准备阶段
Proposer 生成全局唯一且递增的 ProposalID,向 Paxos 集群的所有机器发送 Prepare 请求,这里不携带 value,只携带 N,即 ProposalID。
Acceptor 收到 Prepare 请求后,判断收到的 ProposalID 是否比之前已响应的所有提案的 N 大。
如果是,则——
-
在本地持久化
N
,可记为Max_N
-
回复请求,并带上已经 accept 的提案中
N
最大的 value,如果此时还没有已经 accept 的提案,则返回 value 为空 -
做出承诺,不会 accept 任何小于
Max_N
的提案
如果否,则——
- 不回复或者回复
Error
。
3.2 Phase 2 选举阶段
为了方便描述,我们把 Phase 2 选举阶段继续拆分为 P2a、P2b 和 P2c。
- P2a:Proposer 发送 Accept
经过一段时间后,Proposer 收集到一些 Prepare 回复,有下列几种情况:
(1) 若回复数量 > 一半的 Acceptor 数量,且所有回复的 value 都为空时,则 Porposer 发出 accept 请求,并带上自己指定的 value。
(2) 若回复数量 > 一半的 Acceptor 数量,且有的回复 value 不为空时,则 Porposer 发出 accept 请求,并带上回复中 ProposalID 最大的 value,作为自己的提案内容。
(3) 若回复数量 <= 一半的 Acceptor 数量时,则尝试更新生成更大的 ProposalID,再转到准备阶段执行。
- P2b:Acceptor 应答 Accept
Accpetor 收到 Accpet 请求后,判断:
(1) 若收到的 N
>= Max_N
(一般情况下是等于),则回复提交成功,并持久化 N
和 value;
最后
针对最近很多人都在面试,我这边也整理了相当多的面试专题资料,也有其他大厂的面经。希望可以帮助到大家。
上述的面试题答案都整理成文档笔记。 也还整理了一些面试资料&最新2021收集的一些大厂的面试真题(都整理成文档,小部分截图)
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持。
net/forums/4f45ff00ff254613a03fab5e56a57acb)收录**