分布式系统的挑战

这篇文章会带你学什么？

学完这章后，你将获得：

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

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

---

0. 全景图：为什么需要分布式系统？

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

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

---

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

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

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

为什么只能选两个？

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

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

---

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

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

一致性模型对比

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

---

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

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

挑战之间的关联

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

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

---

4. 共识算法：如何让多台机器"达成一致"

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

4.1 Paxos

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

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

两阶段流程：

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

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	最终一致	中	最高	资金类高可靠场景

---

总结

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

回顾本章的关键要点：

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

延伸阅读

• Designing Data-Intensive Applications - Martin Kleppmann 的分布式系统经典
• The Raft Consensus Algorithm - Raft 官方可视化演示
• CAP Twelve Years Later - Brewer 对 CAP 的重新审视
• Jepsen - 分布式系统正确性测试框架
• 分布式系统模式 - Martin Fowler 的分布式模式合集

---