分布式系统模型与 CAP 定理

🌐 一台机器扛不住了——你该怎么办？

你做了一个校园论坛——最初在一台服务器上跑。后来用户越来越多——CPU 100%、数据库连接满、磁盘快满了……

你买第二台服务器——但问题来了：两台服务器怎么同步数据？用户 A 在服务器 1 上发了帖子，用户 B 在服务器 2 上能不能看到？

这就是分布式系统（Distributed System） 要解决的核心问题：多台计算机协作，让用户觉得”好像在用一台机器”。

📐 定义：分布式系统是一组通过网络连接的独立计算机（节点），它们协作完成共同的任务——对外表现为”一个”系统。

---

🎯 CAP 定理——分布式系统的”不可能三角”

分布式系统有三个理想目标——但最多同时实现两个：

         一致性（C）
         / \
        /   \
       /     \
可用性（A）——分区容错性（P）

C = Consistency（一致性）：所有节点在同一时刻看到相同的数据
A = Availability（可用性）：每个请求都能收到（非错误）响应
P = Partition Tolerance（分区容错性）：节点间网络中断时系统仍能工作

🏪 类比：记笔记

你和同桌一起记笔记（分布式系统的两个节点）。

一致性（C）：你的笔记和同桌的笔记必须一模一样。老师讲到第 10 页——你们的笔记都是第 10 页。

可用性（A）：不管什么时候问你”笔记写到哪了”——你都要能回答。不能因为”我在和同桌同步笔记”就不理人。

分区容错性（P）：你和同桌之间传纸条（通信）被老师截了——你俩还能继续各自记笔记。

关键选择：如果传纸条被截了（网络分区）——

• CP：停止记笔记，等连通再继续（牺牲可用性）
• AP：各自继续记（笔记暂时不一致——牺牲一致性）
• CA：假装传纸条永远不会被截——但现实中不可能

实际中的选择

系统	选择	理由
ZooKeeper/etcd	CP	配置管理必须一致——不可用时宁愿暂停
Cassandra/DynamoDB	AP	电商购物车——即使不一致也不能说”加不了”
传统单机数据库	CA	不分区的单机系统——不涉及 P

💡 注意：CAP 不是”三选二”，而是”P 是必选的（因为网络总会出问题）——所以实际是在 C 和 A 之间选”。

---

🔬 FLP 不可能性

FLP 不可能性（Fischer, Lynch, Patterson, 1985）是一个更”残酷”的理论结果：

在异步通信模型中，即使只有一个节点可能故障，也无法保证在有限时间内达成共识。

通俗说：如果一个节点可能挂掉，而且消息可能延迟——你永远无法确定”共识到底达成了没有”——因为你没法区分”节点挂了”和”消息特别慢”。

这就是为什么共识协议（Paxos/Raft）只能做到”大概率达成共识”，而不是”100% 保证”。

---

💡 BASE——另一种哲学

关系数据库用 ACID（强一致性），但分布式系统常常用 BASE：

BA = Basically Available（基本可用）——系统大部分时间能用
S  = Soft State（软状态）——状态可以临时不一致
E  = Eventually Consistent（最终一致性）——但最终会一致

ACID vs BASE：

• ACID：银行转账——必须立刻一致
• BASE：社交媒体的点赞数——晚几秒更新没人介意

---

📝 小结

概念	一句话
分布式系统	多台机器协作——看起来像一台
CAP 定理	C(一致)、A(可用)、P(分区) 最多同时满足两个
CP vs AP	网络分区时——等同步（CP）或继续各自工作（AP）
FLP 不可能性	异步系统中无法保证有限时间内达成共识
BASE	分布式系统的”妥协”哲学——最终一致

为什么先学这个？ CAP 是所有分布式系统的理论基础。下一步看怎么在现实中达成共识——一致性协议（Paxos, Raft）。