第6章 共识与容错机制

第6章 共识与容错机制

本章跟着一条线走：多台机器之间，最难的从来不是"存数据"，而是"就同一个决定达成一致"。这条线从共识问题的抽象出发，讲清 Paxos 如何证明"一群机器能达成一致"、Raft 如何把它变得可读可工程化，再用 Quorum 的读写票数点破一致性的经济账，最后把容错范畴从"崩溃容错"推到"拜占庭容错"，并讲清楚当节点倒下时，系统靠什么发现、靠什么复盘。

本章路线图

一条主线

第 5 章渲染了大量事务：2PC 里的协调者说了算、MVCC 里的版本要按序、副本要同步……这一切背后都藏着一个更原始的问题——机器们凭什么信任"这个协调者是对的"、信任"这份日志没被改过"、信任"多数意见是传说"？ 一句话：他们要就"什么是真"达成一致，而共识算法就是回答这个问题的那套机制。这一章主线把"共识"从童话讲成工程：Paxos 负责证明"可能"，Raft 负责把"可能"变成"能落地"，Quorum 负责把"要几个副本点头"算到经济"，最后 BFT 把信任模型再放宽。

沿途站点

• 6.1 Paxos：共识问题的理论解，用"提案与批准"证明一群机器总能收敛到一个值。主线推进到：共识是可能的。
• 6.2 Raft：把 Paxos 的复杂性收敛进"选主+日志复制+任期"三件套，成为工程主流。主线推进到：共识是可以落地工程的。
• 6.3 Quorum：读写到底要凑几个票才安全——N、W、R 的组合与那条 W+R 大于 N 的铁律。主线推进到：一致性的成本可以被量化。
• 6.4 拜占庭容错与故障恢复：从"崩了"的故障模型放宽到"坏蛋会撒谎"的拜占庭模型，以及节点故障怎么被检测、怎么自愈。主线推进到：容错不是单一档位，而是可以有等级的。

拐点与结论

本章最重要的认知转折是："多数"不是糊弄字，而是一条有数学保证的分界线。只要系统用的是"奇数个节点的多数投票"，那么当"活着且同意的节点数 + 利用到的旧节点数"超过总数一半时，这些意见就不可避免地交集——这正是 Paxos/Raft/Quorum 都能保证安全性的共同内核。学会看"多数怎么在任意两个决策之间制造交集"，你就抓住了整个共识系列的命门，而不必死记每个算法的细节。

读完你应该

1. 描述共识问题要保证的两件事：安全性（不错）与活性（不停滞）。
2. 复述 Raft 的选主、任期与日志复制的核心流程。
3. 计算并解释 W+R 大于 N 这条 Quorum 铁律。
4. 区分崩溃容错与拜占庭容错在"故障模型"上的差别。
5. 说明故障检测怎么靠心跳/租约发现失联，以及副本如何重建自愈。

多数交集：整章都围着它转

把整章的信息拧成一句可随身带走的话："多数"之间必然相交，相交处就是安全的落脚点。 假设有 3 个节点，任何两轮"拿到 2 票多数"的决策，都必然至少共享 1 个节点——正是这位"见证过上次决策"的节点，把旧约束传染给了新决策，才保证了新决策不会推翻历史。Paxos 靠"法定多数 + 递增编号"实现它，Raft 靠"选主 + 已提交日志不丢"实现它，Quorum 靠"W+R 大于 N"实现它，三者的表达不同、内核同一。看懂这句，后面读 6.1 到 6.4 你会始终知道自己正站在这条数学生存线上的哪个位置，而不至于在算法细节里迷路。

下一章的接力

机器就"对"达成一致之后，数据才敢落地；而落地之后要把它读得快，又是另一场硬仗。第 7 章进入分布式查询优化：规划、数据传输与下推、Join 策略，让跨节点查询不再靠撞运气。第 6 章打好的"一致"地基，喂给第 7 章"读得快"的追求。