说到分布式，重要的 Paxos 算法你看透了么？，简述 mybatis 工作原理

需要配合一个获取最新成功提交的版本号的 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；

(2) 若收到的 N < Max_N，则不回复或者回复提交失败。

• P2c：Proposer 统计投票

经过一段时间后，Proposer 会收集到一些 Accept 回复提交成功的情况，比如：

(1) 当回复数量 > 一半的 Acceptor 数量时，则表示提交 value 成功，此时可以发一个广播给所有的 Proposer、Learner，通知它们已 commit 的 value；

(2) 当回复数量 <= 一半的 Acceptor 数量时，则尝试更新生成更大的 ProposalID，转到准备阶段执行。

(3) 当收到一条提交失败的回复时，则尝试更新生成更大的 P

【一线大厂Java面试题解析+核心总结学习笔记+最新架构讲解视频+实战项目源码讲义】
浏览器打开：qq.cn.hn/FTf 免费领取

roposalID，也会转到准备阶段执行。

Paxos 常见的问题

1. 如果半数以内的 Acceptor 失效，如何正常运行？

在 Paxos 流程中，如果出现半数以内的 Acceptor 失效，可以分为两种情况。