2024年最全说到分布式，重要的Paxos算法你看透了么？，2024最新Java框架体系架构面试题-CSDN博客

本文链接：https://blog.csdn.net/wsjh156456/article/details/138555092

最后

我还通过一些渠道整理了一些大厂真实面试主要有：蚂蚁金服、拼多多、阿里云、百度、唯品会、携程、丰巢科技、乐信、软通动力、OPPO、银盛支付、中国平安等初，中级，高级Java面试题集合，附带超详细答案，希望能帮助到大家。

新鲜出炉的蚂蚁金服面经，熬夜整理出来的答案，已有千人收藏

还有专门针对JVM、SPringBoot、SpringCloud、数据库、Linux、缓存、消息中间件、源码等相关面试题。

新鲜出炉的蚂蚁金服面经，熬夜整理出来的答案，已有千人收藏

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录

需要这份系统化的资料的朋友，可以点击这里获取

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 个过程。