# 分布式系统原理

::: tip 前言
**当一台机器不够用时，问题才真正开始。** 分布式系统是现代互联网的基石——从微信消息到淘宝下单，背后都是成百上千台机器协同工作。但"分布式"不是免费的午餐，它带来了一系列单机系统从未遇到的挑战。
:::

**这篇文章会带你学什么？**

学完这章后，你将获得：

- **核心定理**：理解 CAP 定理及其对系统设计的影响
- **一致性模型**：区分强一致性、最终一致性、因果一致性
- **八大挑战**：掌握分布式系统面临的核心难题
- **共识算法**：了解 Paxos、Raft 等分布式共识的基本思想
- **实战模式**：熟悉 2PC、Saga、CRDT 等常用解决方案

| 章节 | 内容 | 核心概念 |
|-----|------|---------|
| **第 1 章** | 为什么需要分布式 | 扩展性、可用性、地理分布 |
| **第 2 章** | CAP 定理 | 一致性、可用性、分区容错 |
| **第 3 章** | 一致性模型 | 强一致、最终一致、因果一致 |
| **第 4 章** | 八大挑战 | 网络、时钟、分区、脑裂等 |
| **第 5 章** | 共识算法 | Paxos、Raft、ZAB |
| **第 6 章** | 分布式事务 | 2PC、Saga、TCC |

---

## 0. 全景图：需要分布式系统的原理

单机系统简单可靠，但有三个无法逾越的瓶颈：

| 瓶颈 | 说明 | 分布式的解法 |
|------|------|-------------|
| 性能上限 | 单机 CPU、内存、磁盘有物理极限 | 水平扩展：加更多机器分担负载 |
| 单点故障 | 一台机器挂了，整个服务就挂了 | 冗余副本：多台机器互为备份 |
| 地理延迟 | 用户在全球各地，单机只能在一个地方 | 多地部署：就近服务用户 |

::: tip 分布式的代价
分布式系统解决了上面的问题，但引入了新的复杂性：网络不可靠、时钟不同步、部分失败、数据一致性……这些就是本文要讨论的"挑战"。

**Peter Deutsch 的分布式计算八大谬误**告诉我们，以下假设在分布式环境中都是错的：
1. 网络是可靠的
2. 延迟是零
3. 带宽是无限的
4. 网络是安全的
5. 拓扑不会变化
6. 只有一个管理员
7. 传输成本是零
8. 网络是同构的
:::

---

## 1. CAP 定理：分布式系统的"不可能三角"

2000 年，Eric Brewer 提出了 CAP 猜想（后被证明为定理）：一个分布式系统最多只能同时满足以下三个属性中的两个。

| 属性 | 含义 | 通俗理解 |
|------|------|---------|
| **C**onsistency（一致性） | 所有节点在同一时刻看到相同的数据 | 你在任何 ATM 查余额，结果都一样 |
| **A**vailability（可用性） | 每个请求都能收到非错误的响应 | 系统永远能回应你，不会说"服务不可用" |
| **P**artition tolerance（分区容错） | 网络分区时系统仍能继续运行 | 即使部分网线断了，系统还能工作 |

<CAPTheoremDemo />

### 只能选两个的设计理由

在分布式环境中，网络分区（P）是不可避免的——光纤会被挖断、交换机会故障、数据中心会断网。所以 P 是必选项，实际的选择是在 C 和 A 之间权衡：

- **选 CP**：分区时拒绝不确定的请求，保证数据正确 → 适合金融、库存
- **选 AP**：分区时继续服务，但数据可能暂时不一致 → 适合社交、内容

::: tip CAP 不是非黑即白
现实中的系统不是简单的"CP 或 AP"。很多系统在不同操作上做不同的选择——比如同一个数据库，读操作可以是 AP（允许读旧数据），写操作可以是 CP（要求多数确认）。
:::

---

## 2. 一致性模型：数据同步的"严格程度"

一致性不是一个开关（有或没有），而是一个光谱。不同的一致性模型在"正确性"和"性能"之间做不同的权衡。

<ConsistencyModelsDemo />

### 一致性模型对比

| 模型 | 保证 | 延迟 | 适用场景 |
|------|------|------|---------|
| 强一致性 | 读到的一定是最新写入的值 | 高（需等待同步） | 银行转账、库存扣减 |
| 最终一致性 | 最终所有副本会一致，但中间可能读到旧值 | 低（写入立即返回） | 社交动态、DNS |
| 因果一致性 | 有因果关系的操作保证顺序 | 中等 | 评论回复、协作编辑 |
| 线性一致性 | 所有操作看起来像在单机上按顺序执行 | 最高 | 分布式锁、选主 |
| 会话一致性 | 同一会话内保证读到自己的写入 | 低-中 | 用户个人数据 |

::: tip "读己之写"一致性
最常见的实际需求是：用户修改了自己的数据后，自己能立即看到更新（但其他用户可以稍后看到）。这叫"Read Your Own Writes"一致性，是最终一致性的一个实用增强。
:::

---

## 3. 八大挑战：分布式系统的"地雷阵"

分布式系统的复杂性不是来自某一个问题，而是多个问题交织在一起。以下是最核心的八大挑战。

<DistributedChallengesDemo />

### 挑战之间的关联

这八大挑战不是孤立的，它们相互关联：

- **网络不可靠** → 导致 **网络分区** → 触发 **CAP 权衡**
- **时钟不同步** → 导致 **事件排序困难** → 影响 **数据一致性**
- **部分失败** → 可能导致 **脑裂** → 需要 **共识算法** 来解决
- **数据一致性** → 需要 **分布式事务** → 但事务又受 **网络不可靠** 影响

::: tip 没有银弹
分布式系统没有"完美"的解决方案，只有"合适"的权衡。理解这些挑战的本质，才能在设计系统时做出正确的取舍。
:::

---

## 4. 让多台机器"达成一致的实现

共识算法是分布式系统的核心——它解决的问题是：多个节点如何就某个值达成一致？即使部分节点故障或网络延迟。

### 4.1 Paxos

Leslie Lamport 在 1990 年提出，是第一个被严格证明正确的共识算法。

| 角色 | 职责 |
|------|------|
| Proposer | 提出提案（值） |
| Acceptor | 投票接受或拒绝提案 |
| Learner | 学习最终被选定的值 |

**两阶段流程**：
1. **Prepare 阶段**：Proposer 发送提案编号，Acceptor 承诺不再接受更小编号的提案
2. **Accept 阶段**：Proposer 发送具体值，多数 Acceptor 接受则提案通过

::: tip Paxos 的问题
Paxos 虽然正确，但出了名的难以理解和实现。Lamport 自己的论文用了一个希腊议会的比喻，结果让更多人困惑了。
:::

### 4.2 Raft：为可理解性而生

2014 年 Diego Ongaro 提出 Raft，目标是做一个"容易理解的 Paxos"。它把共识问题分解为三个子问题：

| 子问题 | 说明 |
|--------|------|
| Leader 选举 | 集群中选出一个 Leader，所有写入都经过 Leader |
| 日志复制 | Leader 将操作日志复制到所有 Follower |
| 安全性 | 保证已提交的日志不会被覆盖 |

**Raft 的核心流程**：
1. 集群启动时，所有节点都是 Follower
2. 如果 Follower 超时没收到 Leader 心跳，就变成 Candidate 发起选举
3. 获得多数票的 Candidate 成为新 Leader
4. Leader 接收客户端请求，将日志复制到多数节点后提交

### 4.3 共识算法对比

| 算法 | 提出时间 | 可理解性 | 使用系统 |
|------|---------|---------|---------|
| Paxos | 1990 | 困难 | Google Chubby |
| Raft | 2014 | 容易 | etcd、Consul、TiKV |
| ZAB | 2011 | 中等 | ZooKeeper |
| EPaxos | 2013 | 困难 | 学术研究为主 |

---

## 5. 分布式事务：跨节点的"全有或全无"

单机数据库的事务靠本地锁和日志就能实现 ACID。但当一个业务操作涉及多个服务/数据库时，如何保证原子性？

### 5.1 两阶段提交（2PC）

最经典的分布式事务协议，分为两个阶段：

| 阶段 | 协调者动作 | 参与者动作 |
|------|-----------|-----------|
| Prepare | 问所有参与者"能提交吗？" | 执行操作但不提交，回复 Yes/No |
| Commit | 如果全部 Yes，发送 Commit | 正式提交；如果有 No，全部回滚 |

**2PC 的问题**：
- **阻塞**：Prepare 后如果协调者挂了，参与者会一直等待
- **单点故障**：协调者是单点，挂了整个事务卡住
- **性能差**：需要多次网络往返，锁持有时间长

### 5.2 Saga 模式

Saga 把一个大事务拆成多个本地事务，每个本地事务有对应的补偿操作。如果某一步失败，就逆序执行补偿。

**电商下单的 Saga 示例**：

| 步骤 | 正向操作 | 补偿操作 |
|------|---------|---------|
| T1 | 创建订单（待支付） | 取消订单 |
| T2 | 扣减库存 | 恢复库存 |
| T3 | 扣减余额 | 退还余额 |
| T4 | 确认订单（已支付） | — |

如果 T3（扣减余额）失败：执行 C2（恢复库存）→ C1（取消订单）。

**两种编排方式**：
- **编排式（Choreography）**：每个服务监听事件，自行决定下一步。简单但难以追踪全局状态
- **协调式（Orchestration）**：有一个中心协调者控制流程。清晰但协调者是单点

### 5.3 TCC（Try-Confirm-Cancel）

TCC 是 2PC 的业务层实现，把每个操作分为三个阶段：

| 阶段 | 说明 | 示例（扣库存） |
|------|------|---------------|
| Try | 预留资源，但不真正执行 | 冻结 10 件库存（可用库存 -10，冻结库存 +10） |
| Confirm | 确认执行，消耗预留资源 | 冻结库存 -10（真正扣减） |
| Cancel | 取消预留，释放资源 | 冻结库存 -10，可用库存 +10（恢复） |

### 5.4 三种方案对比

| 方案 | 一致性 | 性能 | 复杂度 | 适用场景 |
|------|--------|------|--------|---------|
| 2PC | 强一致 | 低 | 中 | 数据库层面的跨库事务 |
| Saga | 最终一致 | 高 | 高 | 长流程业务（订单、物流） |
| TCC | 最终一致 | 中 | 最高 | 资金类高可靠场景 |

::: tip 实际选择建议
- 能用单库事务就不要用分布式事务
- 大多数业务场景用 Saga + 消息队列就够了
- TCC 适合对一致性要求极高的金融场景，但开发成本很高
- 2PC 适合数据库中间件（如 ShardingSphere）自动处理
:::

---

## 总结

分布式系统是现代互联网的基础设施，但它的复杂性远超单机系统。理解这些挑战不是为了"解决"它们（很多是根本性的），而是为了在设计系统时做出正确的权衡。

回顾本章的关键要点：

1. **CAP 定理**：网络分区不可避免，实际选择是在一致性和可用性之间权衡
2. **一致性模型**：从强一致到最终一致是一个光谱，根据业务需求选择
3. **八大挑战**：网络不可靠、时钟不同步、网络分区、脑裂等相互关联
4. **共识算法**：Raft 是目前最实用的共识算法，etcd/Consul 都基于它
5. **分布式事务**：Saga 适合大多数场景，TCC 适合金融场景，2PC 适合数据库层

## 延伸阅读

- [Designing Data-Intensive Applications](https://dataintensive.net/) - Martin Kleppmann 的分布式系统经典
- [The Raft Consensus Algorithm](https://raft.github.io/) - Raft 官方可视化演示
- [CAP Twelve Years Later](https://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed/) - Brewer 对 CAP 的重新审视
- [Jepsen](https://jepsen.io/) - 分布式系统正确性测试框架
- [分布式系统模式](https://martinfowler.com/articles/patterns-of-distributed-systems/) - Martin Fowler 的分布式模式合集