第1章：分布式理论基础

大家好，我是老张。今天咱们聊聊分布式系统的地基——那些理论。

说实话，我见过太多人一上来就撸代码，结果系统上线后各种翻车。为什么？因为没搞懂这些基础理论。你想想看，盖楼不打地基，能稳吗？

1.1 CAP理论：分布式系统的“不可能三角”

CAP理论是分布式系统的入门第一课。它说：一个分布式系统，最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition Tolerance）中的两个。

我个人习惯把这个理论记成“三选二”。但注意，不是让你随便选两个，而是要看业务场景。

为什么说P是必须的？因为网络一定会出问题。我在项目中遇到过机房光纤被挖断的情况，那时候分区就发生了。所以，实际生产中我们只能在CP和AP之间选。

1.2 BASE理论：向现实妥协的艺术

CAP理论太理想化了。现实中，我们往往需要“基本可用”而不是“永远可用”。这就是BASE理论的由来。

BASE是Basically Available（基本可用）、Soft State（软状态）、Eventually Consistent（最终一致性）的缩写。

• 基本可用：系统允许部分功能降级。比如双十一，支付页面可能加载慢一点，但不能挂掉。
• 软状态：允许数据中间状态存在。比如你转账后，对方账户可能延迟几秒才到账。
• 最终一致性：经过一段时间后，所有数据最终会一致。说白了，就是“迟早会好”。

我曾经做过一个订单系统，一开始追求强一致，结果性能惨不忍睹。后来改成最终一致性，用户体验反而更好了。为什么？因为用户更在乎“下单成功”的反馈，而不是“数据立刻同步到所有节点”。

1.3 一致性协议：从2PC到Raft

理论说完了，怎么落地？靠一致性协议。我按时间线给大家捋一捋。

1.3.1 2PC（两阶段提交）

2PC是最早的分布式事务协议。分两步：

1. 准备阶段：协调者问所有参与者：“能提交吗？”参与者回答：“能”或“不能”。
2. 提交阶段：如果所有人都说“能”，协调者就通知提交。否则回滚。

听起来简单，但问题很大。我在项目中遇到过协调者挂了，所有参与者都卡住的情况。这就是2PC的致命伤——同步阻塞。

1.3.2 3PC（三阶段提交）

3PC在2PC基础上加了一个“预提交”阶段，试图解决阻塞问题。但说实话，效果有限。我很少在生产环境看到3PC，因为它太复杂了，而且依然无法完全解决数据不一致。

1.3.3 Paxos

Paxos是Lamport大神提出的，被认为是分布式一致性协议的“圣经”。但说实话，它太难懂了。我当年啃了三个月才搞明白。

Paxos的核心思想是：通过多数派投票达成一致。只要超过一半的节点同意，就认为决策通过。

1.3.4 Raft

Raft是Paxos的“简化版”。它把一致性协议拆成了三个子问题：

• 领导者选举：选出一个Leader，负责处理所有写请求。
• 日志复制：Leader把操作日志复制到所有Follower。
• 安全性：保证日志的一致性。

我个人特别喜欢Raft，因为它好理解。你看，Leader挂了就重新选，日志不一致就覆盖，多直观。

下面我用一张图展示Raft的日志复制流程：

嗯，这张图展示了Raft的核心流程。Leader收到请求后，先把日志写到本地，然后并行复制给所有Follower。等多数派确认了，Leader就提交日志，然后通知Follower也提交。

1.4 总结：怎么选？

说了这么多，到底怎么选？我给大家一个简单的决策树：

场景	推荐协议	原因
金融交易、账户余额	2PC + 补偿机制	需要强一致，但要做好回滚准备
配置管理、服务发现	Raft（如etcd、Consul）	好理解，性能也不错
日志复制、消息队列	Raft或Paxos	需要高可用和数据一致
缓存、商品详情	最终一致性（BASE）	性能优先，允许短暂不一致

---