Part IV · 分布式系统 · 第 10 章
10

当机器们意见不合

单机 bug 已经够烦；多机系统还要面对消息丢失、延迟未知、节点宕机和时钟不可信。分布式系统不是高级主题，而是云的默认现实。

难度 硬核主线 用时 约 65 分钟 交互 副本写入流程 · CAP/Quorum 取舍 路线 螺旋式：先抓大图，再深入机制

0先把地图摊开

单机 bug 已经够烦；多机系统还要面对消息丢失、延迟未知、节点宕机和时钟不可信。分布式系统不是高级主题，而是云的默认现实。 本章不会把概念排成术语表，而是沿着一条真实系统路径走：先看它解决什么痛点，再看 OS/云平台怎样实现，最后回到工程取舍。

部分失败系统的一部分坏了，其他部分还在运行，这是分布式最难的故障形态。
CAP网络分区下，一致性和可用性无法同时完全保证。
共识让多个节点对同一个值和顺序达成一致的协议族。
时钟机器本地时间不等于全局真相，顺序需要协议维护。
当机器们意见不合 · 核心流程 分步动画 点击节点或用键盘 ← →
图 10.1核心机制路径。把这一章最容易散掉的流程压成可播放的五步。

10.1分布式的难点不是机器多

如果所有节点永远可靠、网络永远即时，那分布式只是并行程序。真正困难在于你不知道远端是慢了、断了，还是死了。超时不是事实，只是怀疑。

10.2部分失败改变一切

单机失败通常是全停；分布式失败可能是一半系统继续做决定，另一半看不见它。最危险的不是失败，而是不同节点对失败的认知不同。

10.3CAP 是警告，不是架构图

CAP 说网络分区发生时，系统必须在继续响应和保持强一致之间做选择。现实设计更细：延迟、读写比例、业务可接受的不一致窗口，都要进来。

10.4共识给顺序一个来源

Raft/Paxos 这类协议通过 leader、term、log、majority 让多个节点对操作顺序达成一致。它们不让故障消失，只让故障下的决定有规则。

10.5云服务的语义都是分布式选择

数据库的 strong/session/eventual consistency，队列的 at-least-once，存储的 read-after-write，都是对失败模型和业务需求的具体回答。

当机器们意见不合 · 取舍实验 可玩模拟器 切换策略，看指标怎么变
图 10.2工程取舍。云和 OS 的概念真正进入工程时，几乎都不是“选最好”，而是在约束之间找一个诚实的点。

↔云与 OS 的桥

这一章不是孤立知识点。下面这张表把它和前后章节接起来：你会看到，同一个机制在单机、云平台和 AI 基建里会换名字，但问题结构没变。

本章机制云上形态为什么重要
共识日志etcd、Kubernetes API serverK8s 控制面靠强一致元数据推进集群状态。
最终一致对象存储、缓存、搜索索引读旧数据可能可接受，但必须被产品语义承认。
超时重试、幂等、熔断你不知道远端是否执行过，所以 API 设计必须支持重复请求。
深潜 读完本章后，怎么确认自己真的懂了？›

不要只背定义。你应该能把一个线上现象翻译回机制：慢在哪里、谁在排队、哪个抽象漏了、哪个资源被过度承诺。下面三个检查点可以当成小作业。

本章收束 · 你现在握住了什么

  • 分布式最难的是部分失败和不同节点认知不一致。
  • CAP 讨论的是网络分区下的一致性/可用性取舍。
  • 共识协议给多副本系统提供操作顺序来源。
  • 云服务的每种一致性语义都是业务和失败模型的折中。

有了分布式理论，我们看一个把它工程化到日常运维里的系统：Kubernetes。