6.1 Paxos 共识的理论解

6.1 Paxos：共识问题的理论解

Paxos 回答的问题是"一群彼此不信任、还会宕机的机器，能否就同一个值达成一致"。它用"提案者提、接受者批、多数通过才生效"的简单机制证明了这件事是可能的。本节先讲清共识要守的两条底线，再拆开 Paxos 的一轮投票，最后点破它让人望而生畏的地方——不是难懂，是工程落地难。

学习目标

阅读完本节，你应当能够：

1. 说出共识问题的定义，以及安全性与活性两条底线。
2. 用提案者、接受者、多数交集描述一轮 Paxos 表决。
3. 解释为什么"多数"能保证任意两轮决策不冲突。

先把"共识"这词说人话

想象一群参加会议但互相不信任的代表，要定一个会费标准，而且允许有人半路撂挑子、有人晚到很久、有人网络不稳定。他们怎么保证最后所有人都能认定"就是那个价"？这就是分布式共识问题。它要给的是两个保票：安全性——任何两个人最终认的那个值绝不打架；活性——只要大家还在交流，讨论就不至于永远卡死。听起来像开会的常识，站在分布式里却是极难的，因为没有任何人"绝对可信、绝不宕机"，你唯一能依赖的，是"多数"。

一、Paxos 的舞台：两个角色

Paxos 把参与者分成两类：提案者负责提一个值（比如"新 leader 是节点 X"或"这条日志该写什么"）；接受者负责批复"我接受这个提案"。协议的精妙在于：一个值只有当它被超过半数的接受者接受时才算真正生效。为什么是"超过半数"？因为任意两组"超过半数"的接受者必然有交集（一半加一半必然相撞），于是任何两个决策之间都能被追到一个"至少有一个接受者两头都点过名"的共同点——这个多数交集，就是安全性的全部秘密。

二、一轮表决长什么样

简化地说，一轮 Paxos 近似这样走：提案者发出一个带编号的提议"我提 V1，编号 N5"，接受者们比较编号，若比之前见过的新，就回"我接受 V1（若我此前已承诺接受 V0，则我更倾向 V0）"；当提案者拿到多数接受者的认可后，就广播"最终定 V"。真实协议里还有"承诺不再接受更低编号"的加锁细节，但核心骨架就是"提案一提名、多数一批、凭多数交集定终身"。

一轮 Paxos 的核心流程

三、多数交集：安全性的几何直觉

如果你觉得"过半"只是感觉上稳，其实它有个漂亮的几何解释：在一个五人小组里，任意两组"占三人的多数"必然至少撞到一个人。把这个直觉放大到共识——任意两轮决策各自拿到了各自的多数，那么两轮之间至少共享一个接受者，这个共享者就能证明"后一个决定继承了前一个的信息"，于是两个决策绝不会互相打架。下面这张 SVG 把"两批多数必相交"用两组圆圈画出来：

任意两批多数必然相交

由这个交集，Paxos 引出一整套"编号承诺 + 多数批准"的机制，来把这个直觉变成可执行的协议：任何新编号不能推翻已获批准的旧决定。这正是 Paxos 能在异常复杂的故障环境中保证安全性的根基。

四、它难的不是理解，是工程

Paxos 在理论上证明了"共识可能"，可到了工程落地就暴露两大问题：一是它很绕，标准协议分多个阶段、要处理各种上帝视角的顺序与重试，工程师写过就懂，但维护和向别人解释都费劲；二是它是"多值共识"之上的抽象，想把它的机制直接用在"日志复制"这种连续全权需求上，还得再包装好几层。这些繁琐正是后来 Raft"让共识可教可读"的动机——下一节你会看到，Raft 是把 Paxos 的道理装进了更能直接理解的框架里，而 Paxos 仍是那个底层的理论通顶。

五、多数比你想的更省：三台就能容一台挂

很多人一听"多数"就觉得要很贵，其实它意外地廉价。以 3 台为例，只你要求"任意一轮拿到 2 台批准就算数"，就已能容忍任意 1 台宕机或失联——因为剩下 2 台仍然凑得出一个多数，协议照样能往下走。放大到 5 台、7 台，规律一样：多少个节点的多数，就等于能容忍多少个"总数的一半往下取整"台节点同时出状况，3 容 1、5 容 2、7 容 3。这个"多数虽小、久经考验"的特性，正是 Paxos/Raft 常年当分布式界地基的原因——它没有为"更稳"付出"更贵"的代价，容错是白送的，只要副本数撑得起。

六、用三道自测题把 Paxos 钉牢固

学 Paxos 最容易"读完就忘"，用三道题当场验一验你有没有真懂：

第一问：为什么 Paxos 要以"超过半数接受者"为准，而不是"全部"？ 因为收齐全部往往做不到——节点可能宕机、可能失联，等你凑齐所有，系统早就卡死。而"过半"既能在多数节点活着时继续，又能靠任意两组多数必相交，保证两个决策不冲突。

第二问：两个决策各自过半，为什么就一定不会打架？ 因为两组"过半"的人必然至少共享一个接受者，这个共享者记住了前一个决定的终结，后一个决定必须尊重它——这就是安全性的几何根源。

第三问：能不能不加编号承诺，直接让两个提案各提各的？ 不行。没有编号承诺，两个提案者可能同时各拉到半数、却各说各的值，多数交集仍可能被"读过就忘"破坏。正是"承诺不再接受更低编号"这条细节，把"多数交集"从可能变成了必然。

三道题能脱口而出，你对 Paxos 就从"懂大意"进入"能自洽解释"的水平了。

本节要点回顾

• 共识两底线：安全性（不错）与活性（不停滞）。
• 多数交集：半数以上必然交叠，是安全性的来源。
• 两角色：提案者提名、接受者批复，多数批准才定稿。
• 难在工程：Paxos 理论清晰、落地繁琐，催生 Raft。

Paxos 讲的是"可能"，可"可能"还不足以让工程师放心天天用。下一节 6.2 看 Raft 怎么把共识装进"选举+任期+日志复制"这套更直白的框架，让它成为工程的现实选择。