第 5 章 · 网络与分布式系统

“分布式系统的所有难题，都源于两个不确定性：没有全局时钟，不知道对方是死是活。“

本章覆盖的课程

文档	内容
`00-设计推演：从零造一个共识算法.md`	★ 必读：写三遍 → 多数派 → leader+日志 → term → 投票限制 → 一致性检查 → 提交条件，七次失败演进
`01-网络编程：从 Socket 到 epoll.md`	I/O 模型、epoll 原理、Reactor 模式、手写网络框架
`02-分布式共识：Raft 完整实现.md`	一致性模型、Raft 选主/日志复制/安全性、完整 Go 实现

★ 先读 00-设计推演。 它不给你”Raft 有这些规则”，而是让你自己把每条规则从失败里推出来。

特别是那句：“被多数派复制过” ≠ “已提交”——这是 Raft 实现里最常见的 bug，只有亲手走完那个 5 节点、4 个 term 的崩溃时序，你才会真正记住。

第 1 章我们讲过：单机并发的难题源于”CPU 会抢占”。

分布式系统里，难题源于：

① 没有全局时钟   → 无法判断两个事件的先后顺序
② 网络不可靠     → 消息可能丢失、重复、延迟、乱序
③ 节点可能失败   → 而且你无法区分"节点挂了"和"网络慢"

这三点导致：分布式系统里，“现在发生了什么”这个问题无法被精确回答。

所有的分布式算法（Raft、Paxos、2PC、向量时钟），本质上都是在用额外的通信和约束，重建一个”可以被推理的顺序”。

你在第 1、3 章学过的很多东西，会在这一章以更大的尺度重现：

“让相关的东西物理上靠近” → “让计算靠近数据” “层次化缓存” → “CDN / 多级缓存” “用约束换性能” → “用一致性级别换可用性”

Raft 是这一章的重头戏。它不是”看懂就行”的东西——你必须自己写一遍，才能理解那些看起来莫名其妙的规则。

比如：“为什么 leader 只能提交当前 term 的日志？” ——看论文你可能觉得”哦，是为了安全”，但自己写一遍，构造出那个反例，你才会真正理解。