管理关键状态：用分布式共识做可靠的状态复制

一句话

本章只有一个命题：只要一组进程需要就某个状态达成一致，你面对的就是「分布式共识（distributed consensus）」问题——没有捷径。心跳、超时、时间戳这些轻巧的替代品不是绕开了共识，而是实现了一个错的共识，只是错误要等到网络分区那天才显形。

Glossary · 术语表

坐标

本章在 SRE 书第 IV 部分「管理复杂系统」，作者 Laura Nolan。前两章（Ch21 处理过载、Ch22 级联失效）讲单个服务怎么别把自己拖垮；本章抬高一层，讲多台机器之间的关键状态怎么才不出错。它是全书最偏理论的一章，正面对应 DDIA 第 9 章；后面的 Ch25、Ch26 都以「状态可靠」为前提。

这章要解决什么

本章开篇摆了三个真实（脱敏）的故障案例，共同点是都在试图绕开共识：①脑裂——主备靠心跳判活，网络拥塞让心跳超时、备机自行上位，可主机根本没死，两台同时写文件，事后人工对账且有数据永久丢失；②切换必须叫人——另一套系统为避免脑裂规定主只能人工指定，于是可用性被人的反应时间钉死，还背上一堆琐务（toil）；③自研组成员算法出错——用 gossip 传成员关系、自研判活，网络异常时集群裂成两个各自认为对方已死的组，双写丢数据。

作者的诊断毫不留情：这些系统本来就需要共识，只是作者不承认。「心跳 + 超时」把一个根本无解的问题——异步网络里「没回话」到底是死了还是慢了——当成了能解的。代价不是「偶尔多切一次主」，而是数据分叉；一旦分叉，没有任何自动手段能替你决定哪一份才是对的。

顺带纠正一个常被念歪的经：CAP 说的是分区期间只能在一致（C）与可用（A）之间选一个，而非平时就三选二。共识系统选 C——少数派那侧宁可拒绝服务也绝不分叉，等于把「脑裂」这个不可逆的后果换成「短暂不可用」这个可恢复的后果。

核心内容，讲透

为什么「心跳 + 超时」注定不够

根子在于：异步网络里，「宕机」和「慢」不可区分。收不到心跳，可能是进程崩了，也可能只是它卡在一次长 GC 或网络拥塞——没有任何外部观测能把两者分开。你只能定一个「等多久算死」，而这个阈值无论定多少，都有把活人判死的那天。这就是 1985 年 FLP 不可能性说的事：完全异步模型里只要有一个进程可能崩溃，就不存在既保证安全、又保证有限时间内出结果的确定性算法。

真实系统的绕法很明确：牺牲「一定出结果」，死守「一定安全」——用超时与随机化（Raft 的随机选举超时就干这个）打破僵局；代价是网络极糟时可能反复选举、迟迟选不出主，但永远不会同时选出两个主。土办法恰好把取舍做反了：超时就上位，于是脑裂。

共识的两根支柱：过半数，与同一本日志

支柱一：法定人数相交（quorum intersection）。任意两个「过半数」集合必定至少有一个共同成员。5 副本里任何两个 3 人组都必然重叠，而那个重叠的副本记得自己已为上一届投过票，就会拒绝给冲突的新决定投票——两个互不相交的多数派在数学上不存在，脑裂被从根上堵死。这也解释了为什么偏爱奇数：6 副本的多数派是 4，容错力和 5 副本一样，却白多一台机器、多摊一份延迟。

支柱二：复制状态机（RSM）。共识的产出不是「投票选出一个值」这么单薄，而是一份所有副本内容与顺序都一致的操作日志；每个副本按同序执行同样的确定性操作，状态必然一致。本章说得直白：共识是构建块，复制状态机才是你真正想要的东西——数据库、锁服务、配置存储、消息队列，都是同一个 RSM 换了个接口。

Paxos / Multi-Paxos / Raft，白话版

Paxos（Leslie Lamport）的骨架是两轮：① 抢提案号——候选者带一个全局递增的编号问过半数副本「我能提案吗」，答应的副本承诺此后不再接受更小的编号，并把已知的最新「已接受值」告诉他；② 提案落定——候选者提出值，但若第一轮收到过任何已接受值，它必须沿用那个值，过半数接受即定案。「必须沿用旧值」就是共识不会前后打脸的全部秘密：新多数派一定与旧多数派重叠，所以看得见旧决定，也就推翻不了它。

Multi-Paxos 是实用版：每条日志都跑满两轮太贵，于是推举一个稳定领导者（stable leader）一次性拿下第一轮，之后每条只需一轮，把一次写入压到 1 个网络往返 + 1 次 fsync。Raft（2014）把同一件事重组成「领导者选举 + 日志复制 + 安全性」，并把可理解性当设计目标——它不比 Paxos 更快或更安全，但工程师读得懂、写得对，这本身就是可靠性；etcd、Consul、TiKV、Kafka 的 KRaft 都走 Raft，Zab 则是 ZooKeeper 的变体。

还有一条常被忽略的量级差异：这些算法只防宕机故障（节点会死但不会撒谎），容忍 f 个故障需 2f + 1 个副本；要防拜占庭故障（Byzantine，节点还会发矛盾消息骗人）则陡增到 3f + 1。数据中心内部几乎都只做前者。

共识落地的五种形态

• ① 可靠复制状态机——最本质的形态，下面四种都是它的特例。
• ② 复制数据 / 配置存储——放配置、元数据、服务发现表。它是给低容量、高价值数据用的：Chubby 论文的自我定位原话就是「粗粒度锁 + 低容量的可靠存储」，别拿它存业务数据。
• ③ 高可用处理 / 领导者选举——一主若干热备，主挂了自动选新主。领导者选举与共识是等价问题，而这恰是最多团队想造轮子的地方；GFS、Colossus、Bigtable 都是这个形状。
• ④ 分布式协调与锁服务——锁、屏障（barrier），藏着一个致命细节，下段单说。
• ⑤ 可靠队列与消息——把队列建在共识之上，或用原子广播 / 发布订阅。Google 的 Photon 就靠一个 Paxos 复制的 IdRegistry，跨机房保证广告点击与查询的连接不重复计费。

那个致命细节：分布式锁必须是租约，而且必须带递增序号。持锁者可能被长 GC、虚拟机挂起或网络问题冻住而毫不知情；等它醒来，锁早已过期、被别人拿走，可它还以为持着。解法是让锁服务发一个单调递增的序号（sequencer / fencing token），下游存储必须校验、拒绝旧序号的写入。光有锁不等于正确性——这是本章最值得贴在墙上的一条。

「共识太慢」是个迷思

本章专门反驳一句流传甚广的话：共识太慢、吞吐太低，扛不住正经业务。它确实比单机贵，但贵在两个可预测的地方：网络往返——一次提交至少要等过半数副本回话，写延迟下限就是到「第 3 快的副本」（5 副本时）的往返时间，同机房 RTT 通常亚毫秒、同地域跨机房几毫秒、跨大陆几十毫秒、跨洋一百多毫秒，这是光速定的；磁盘落盘——日志得 fsync 才敢确认，机械盘一次通常几毫秒，SSD / NVMe 可压到亚毫秒。

优化手段也就那么几招：稳定领导者省掉第一阶段；批处理把多条提案合并成一次落盘一次广播，吞吐涨、单条延迟略增；流水线不等上一条确认就发下一条但严格保序，在高带宽高延迟链路上收益最大；Fast Paxos 让客户端直接发给所有副本、省掉绕经领导者那一跳，代价是更大的法定人数；法定人数租约（quorum lease）让部分副本对部分数据持读租约，从而本地直接读还保持强一致；最后，领导者本身是吞吐瓶颈，那就按分片切成多个共识组——Spanner 就是每个 tablet 一个 Paxos 状态机。

部署与监控：几个副本、摆在哪、盯什么

几个。n 个副本容忍 (n-1)/2 个故障。Google 的默认是 5，理由非常实际——要能在一台副本做计划内维护的同时，仍扛得住另一台意外挂掉；3 副本做不到，维护期间等于零冗余。再往上容错涨得慢、延迟与成本涨得快。

摆在哪。铁律是多数派不能落在同一个故障域里：5 副本分 3 个机房（2 + 2 + 1）能扛住任一机房整体失联，全塞进一个机房则机房一挂全完；但分得越开写延迟越高。领导者应靠近写请求最密处。GitHub 那次事故的另一半教训正在此：把自动提主放到跨大陆，等于允许系统在最坏时刻做出一个延迟与一致性都很糟的决定。

盯什么。健康副本数、是否有领导者与领导者变更频率、日志序号与各副本落后程度、提案与接受数、吞吐与延迟分布、RTT 与 fsync 等待。经验判据：领导者频繁抖动、或某个副本持续落后，通常比「整体延迟略高」更早预示故障——它说明系统已在反复重选，只是还没塌。

关键权衡与选型

表 1 · 自研「心跳 + 超时」 vs 用现成共识系统

表 2 · 副本数与摆放：容错、延迟、代价

表 3 · 你想干的事 → 该用哪种形态

为什么重要 / 落到真实系统

这一章对应一道几乎必考的架构题：「你怎么实现高可用的主从切换？」标准答案不是「心跳加虚 IP」，而是把选主交给一个共识系统，并在下游做序号校验（fencing）。今天你身边的系统几乎都是它的实例：Kubernetes 把全部集群状态放在 etcd（Raft）；ZooKeeper（Zab）长期充当 HBase、早期 Kafka 的协调层；CockroachDB、TiKV 把「每个数据分片一个独立 Raft 组」做成标配；Spanner 每个 tablet 一个 Paxos 组。

易错点与争议

• 把锁当正确性保证。没有 fencing token 的分布式锁，在长 GC、虚拟机挂起面前就是纸糊的（图 3）。
• 共识系统会变成全局单点依赖。因为太好用，无数系统把「它永远在」写进隐含假设。Google 的对策是主动给 Chubby 安排计划内停机——正是 SRE 书反复讲的那句：过高的实际可用性会诱导别人依赖你承诺之外的东西。
• CAP 被当成自助餐。它只在分区期间逼你在 C 和 A 之间选一个，更不能用来论证「所以我们不需要一致性」。
• 「共识太慢」多半没测过。真正的瓶颈通常是领导者的位置和跨地域 RTT，而非算法本身。
• Raft 不比 Paxos「更正确」。两者安全性属性一样，Raft 赢在可理解性和对成员变更的完整描述——而成员变更恰是共识实现里最容易写错的部分，这也是「别自研」最强的理由。
• 时代局限。本章 2016 年成书时 Raft 生态刚起步；此后 etcd 随 Kubernetes 普及、Kafka 用 KRaft 去掉了 ZooKeeper。但核心判断——需要共识就用现成的——只被进一步印证。

要点