MIT 6.824 学习记录：Paxos 论文阅读
本周 MIT 6.824 的课程任务聚焦于 Raft 协议，但在正式进入 Raft 论文前，我注意到题目描述中提及 Raft 是“一个比 Paxos 更易理解的共识算法”。出于对基础概念完整性的考虑，我选择先阅读 Leslie Lamport 的经典论文《Paxos Made Simple》，尝试理解 Paxos 共识协议的核心思想
Paxos 的问题背景
Paxos 要解决的是分布式系统中“多个节点如何就一个值达成一致”的问题。它的目标是在网络不可靠（消息可能延迟、重复、丢失）、节点可能崩溃的前提下，依然可以达成：
只有一个值被选中（Only one value is chosen）
被选中的值一定是某个节点提议过的（Only a proposed value may be chosen）
Learner 学到的值必须是真的被选中的值（A process never learns that a value has been chosen unless it actually has been）
注意 Paxos 是 非拜占庭容错 的，它不考虑恶意节点，仅容忍“非恶意故障”如宕机、网络中断。
Paxos 协议结构
Paxos 中有三种逻辑角色：
Proposer：提出某个 value 的提议
Acceptor：投票是否接受某个提议，是“共识裁判”
Learner：学习最终达成共识的值，通常代表客户端或状态机
一个完整的 Paxos 提案需要两个阶段：
Phase 1: Prepare / Promise
Proposer 选择一个全局唯一的提案编号
n，发送 prepare 请求Acceptor 接收到后：
如果该编号
n大于其已承诺的编号，回复 promise，承诺不再接受小于n的提案同时返回自己已接受的最大编号的提案（如有）
Phase 2: Accept / Accepted
Proposer 汇总 responses：
如果有人返回曾接受过某个提案，则选择编号最大的那个值继续提议；否则可自由提议任意值
发送
(accept, n, v)到多数派 acceptors
Acceptor 若尚未承诺更大编号，会接受该提案并回复
若多数 acceptor 接受了该提案，称该值被 chosen，Learner 可据此学习。
编号机制与 higher-numbered proposal
论文中强调：“如果某个编号为 n 的值 v 被选中，那么任何更高编号（n'>n）的提案若被选中，其值也必须是 v。”这是 Paxos 保证一致性的核心不变量。
编号在 Paxos 中的作用类似于以太坊中交易的 nonce，用来解决并发 proposer 竞争的问题，确保不会出现两个提案都被选中。
和 2PC 的对比
我一度将 Paxos 的两阶段机制与 2PC 搞混。实际上，虽然两者都有 prepare + commit 的结构，但 Paxos 与 2PC 的区别如下：
Paxos 更像一个多数派赞成的议会机制，而 2PC 更像一个法官拍板的司法机制。
关于提案（proposal）的理解
刚开始我对 proposal 的理解较混乱，后来结合例子清晰了不少。
以一个分布式 kv 存储为例：
用户想设置
x=42，这个操作就是一个 proposal（提案）Proposer 发起该提案，希望 acceptors 多数接受
若达成多数，proposal 被选中，该值被记录，Learner 学习该值，系统对外“提交”该操作
若有人后来想改为 x=100，必须发起新提案，Paxos 会确保不会同时接受两个值。
此外，我曾疑惑如何区分“更新旧值”和“发起新 slot 的提案”，这个涉及到 Multi-Paxos 的设计，它通过日志 slot 的编号（类似区块高度）区分每一轮共识的位置。
关键困惑与思考
P1 与 P2 是否冲突？
看似 Acceptors 必须接受第一个提案（P1），但同时又要确保继承旧提案的值（P2）
实际上是通过 Phase 1 中返回已有值，再让 proposer 在 Phase 2 中决定“继承旧值”，从而解决
为何不直接选一个 leader 来决定一切？
Paxos 不禁止选 leader，Multi-Paxos 就是在此基础上优化（让 leader 重复提议多个 slot）
Leader 机制会带来单点问题，但换取性能；Paxos 保持基本安全机制即便没有 leader
Paxos 是否是一个完整存储系统？
Paxos 是共识协议，不负责状态存储和应用逻辑；真正的分布式存储系统在 Paxos 基础上构建，比如 Google 的 Chubby、Spanner 使用 Paxos 做日志复制
总结
Paxos 虽然以“简单”为名，但初读依然颇为晦涩。它解决的问题高度通用且抽象，和实际系统之间还隔着一层架构实现。但理解 Paxos 的价值在于，它明确界定了 一致性达成的最小逻辑闭包，是任何分布式系统中关于“共识”的理论基线。
下一阶段我将进入 Raft 的学习，它在保留 Paxos 安全性的同时通过更清晰的 leader 驱动机制简化了工程实现，值得期待
参考资料：
Paxos Made Simple：https://css.csail.mit.edu/6.824/2014/papers/paxos-simple.pdf