分布式系统引论

一句话

你以为分布式的难点是「机器多了不好管」，其实是没有任何观察者能看见「现在」。这一章不给一行算法，它给的是 Part II 全部算法共用的那张假设表——链路（link）有多可靠、时间有多可信、节点会怎么坏。把这三格填错，后面的共识、复制、反熵全都建在流沙上。

Glossary · 术语表

坐标

Part I 讲的是一台机器里的存储引擎（B-tree、LSM-tree、事务恢复）；Part II 从这一章起跨出机器。它上承第 7 章、下启第 9 章故障检测、第 10 章领导者选举、第 11 章复制与一致性、第 12 章反熵与传播，直到第 13–14 章的共识。对应现实里的哪一类系统？所有多副本的东西——etcd / ZooKeeper、Cassandra / DynamoDB、Kafka、Spanner / CockroachDB，它们的分歧全在这一章画出的坐标系里。

这章要解决什么

单机程序员有三条白送的假设：调用必返回、读到即最新、时钟单调向前。跨机之后三条全废，而废掉的方式很隐蔽——不是立刻报错，是平时都对、压力一大就错。书里借 Peter Deutsch 的「分布式计算八大谬误」点名前几条：网络可靠、延迟为零、带宽无限、拓扑不变。

不解决会怎样？三种典型翻车：拿墙上时钟给事件排序——两台机器各自的 now() 在 NTP 校准之间可能差出几毫秒到几十毫秒，于是「后发生」的写被判成先发生，数据被静默覆盖；把超时当死亡——旧主只是 GC 停顿了 8 秒，新主已经选出来了，两个主同时接受写入（脑裂）；网络错误就无脑重试——第一次其实成功了，于是用户被扣了两次款。三种错误都不是「代码写错了」，而是假设表填错了。

核心内容，讲透

一、共享状态：系统里没有「快照」这回事

书里给的定义很朴素：分布式系统就是一组各自独立执行、只靠消息互通的进程。由此推出一个后果——系统里不存在「当前全局状态」这个东西。每个节点手上只有两样：自己的局部状态，和若干条已经到达的消息。没有上帝视角，没有可以一口气拍下来的快照。

所以任何「系统现在是什么样」的说法，都只是某个节点在某个时刻的猜测，而且天生落后——落后的下限就是一次单程网络时延。跨大洲部署时「最新」至少陈旧 50 毫秒，这不是实现不好，是光速。

二、链路阶梯：不可靠是底座，可靠是垒出来的

本章最实用的一节。它把「网络」拆成三层抽象，层层加码：

• 公平损失链路（fair-loss link）：消息可能丢、可能重复、可能乱序，但保证一件事——只要你无限次重发，就有无限次送达。它不保证任何一条消息，只保证不会「永远针对性地吞掉你」。
• 固执链路（stubborn link）：在公平损失之上加一条「发出去就不停重发，永不停止」。于是得到最终必达，代价是收件方会收到大量重复、而且顺序乱。
• 完美链路（perfect link）：固执链路 + 按消息 ID 去重。它给三条保证：有效性（发出去的终会送达）、无重复（同一条不会交付两次）、无凭空创造（没发过的不会冒出来）。

要带走的一句：「可靠链路」不是网络的性质，是你用重试和记账在不可靠网络上盖出来的一层楼。而且盖得并不彻底——现实里「无限重发」永远是「重试 N 次 + 超时放弃」，所以完美链路是理想模型，不是你能买到的产品。

三、消息顺序，与「恰好一次」的真相

顺序保证也是阶梯，四档由弱到强：无序（到达顺序任意）→ FIFO 序（同一个发送者发出的消息，按发送顺序交付）→ 因果序（causal order）（有因果关系的消息不会颠倒，互不相干的可任意）→ 全序（total order）（所有节点看到完全相同的一串顺序）。越往上越贵：FIFO 只需每条链路一个递增序号；因果序要带上因果元数据（向量时钟）；全序基本等价于要过一次共识，这就是第 13–14 章的活。

投递语义同样三档：至多一次（发了就不管，可能丢）、至少一次（重试到确认，可能重）、恰好一次。第三档是全章最该记住的结论：在链路层面，恰好一次不可能。发送方收到一个失败或超时时，它无法区分「消息没到」和「消息到了、处理了、但回执丢了」——唯一可信的状态是成功。工程上所说的「恰好一次」，实际上永远是至少一次 + 接收方幂等去重：消息带唯一 ID，接收方维护一张已处理 ID 表。

四、两将军与 FLP：两条不可能结论

两将军问题（Two Generals' Problem）：两支军队分处山谷两侧，只能派信使穿越敌营商定同时进攻，信使可能被截。结论是：无论交换多少轮确认，最后一条消息的发送方永远无法确定它送到了没有。在可能丢消息的链路上，两方无法就「同时行动」达成确定的一致。

FLP 不可能性（Fischer–Lynch–Paterson，1985）：在异步系统里，哪怕只有一个进程可能崩溃，也不存在既保证终止又保证一致的确定性共识算法。根子还是那句老话——异步系统里分不清「崩了」和「只是很慢」。

关键不是「所以共识做不了」，而是它告诉你必须松开哪个螺丝：加时间假设（用超时把系统当成部分同步——Raft、Paxos 的路线）、放弃确定性（随机化共识）、或放弃「一定终止」的承诺（永不出错，但极端调度下可能一直选不出主）。真实系统几乎都选第一条：用超时换活性，并接受超时偶尔骗你。

五、系统同步性：三档时间假设

同一个算法，在不同的时间假设下结论完全不同，所以这一格必须先填：

• 同步系统：消息传递与处理时间都有已知上界。超时于是成了可靠的故障判据，算法写起来最舒服——但真实网络给不出这个上界。
• 异步系统：没有任何时间上界，时钟不可用。最贴近真实，但 FLP 堵在门口。
• 部分同步（partially synchronous）：大多数时候有界，偶尔超出。这是现实系统的落脚点——Raft 的选举超时、第 9 章的 φ-accrual 故障检测器，都是在这一档里做工程。

六、故障模型：假设对方会怎么坏

最后一格是「坏」的形状，从便宜到昂贵：

• 崩溃停止（crash-stop）：一旦挂掉就永远不回来。最好分析，也最不现实。
• 崩溃恢复（crash-recovery）：挂了还会回来，而且带着一份可能已经过期的状态。于是必须有持久化日志 + 重新追平机制。
• 遗漏故障（omission fault）：进程活着，但漏发或漏收若干消息——过载丢包、长 GC 停顿都属此类。最阴险的一种，因为它看起来还活着。
• 拜占庭故障（Byzantine fault）：任意行为，包括撒谎、给不同节点报不同的值。容忍它的代价是硬性的：容忍 f 个崩溃需要 2f+1 个节点，容忍 f 个拜占庭需要 3f+1。

数据库系统默认不做拜占庭假设——机器都在同一个组织的机房里，不值得为撒谎付三倍的账；把这一格打开的是区块链那一类互不信任的场景。

关键权衡与选型

表 1 · 投递语义：你想承诺什么，就得付什么

表 2 · 时间假设：填错这一格，算法要么写不出、要么活不下来

表 3 · 故障模型：假设越离谱，副本越贵

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

这一章的价值在于：它把「分布式很难」这句废话，换成了三个能在设计评审上直接开口问的问题——我们假设的是哪一档链路？哪一档时间模型？哪一档故障模型？面试里同理：被问「怎么保证消息不重不漏」，答「用 MQ 的 exactly-once」是没分的，答「链路层做不到恰好一次，所以做至少一次投递 + 接收端幂等去重，去重表按业务 ID 建、保留 7 天」才是懂行的回答。

易错点与争议

• 「超时了就是挂了」——错。超时只说明「这段时间内我没收到回音」。把它当死亡判据，就得接受偶尔的误判；真正的防线不是把超时调得更准，而是让误判无害（fencing token、lease 过期后主动退位）。
• 「重试总是安全的」——只有幂等时才安全。非幂等操作上加重试，等于给自己装了一个概率性的重复执行器。
• 「机器越多越容错」——偶数不买账。4 节点和 3 节点的容错能力一样，都是 1 台；多出的那台只增加协调成本和分区时形成僵局的机会。
• 「CAP 说你必须在 C 和 A 里二选一」——被过度传播了。Brewer 自己的表述是：只有在真正发生分区时才需要放弃一致性或可用性，平时两者可以兼得。
• 「这些都是理论，工程上不重要」——反例就在上面。Dataflow 那句「Deadline Exceeded 是有歧义的」，就是两将军问题在一行 RPC 错误码上的显形。
• 本章自身的局限。它是一张「术语与模型的地图」，干净但也干燥：真正把部分同步落地的工程手段（lease、混合逻辑时钟 HLC、fencing token）基本没展开，要等后面几章甚至别的书来补。

要点