分布式系统的“不可能三角”：深入理解 CAP 定理

一个分布式系统，部署在三个机房。某个时刻，机房 A 和机房 B 之间的网络突然断了。此时一个用户修改了机房 A 的数据，另一个用户从机房 B 读数据——她应该读到旧数据，还是直接告诉”系统不可用”？

这个问题没有正确答案。分布式系统的设计者必须做出选择。 这个选择，就是 CAP 定理的核心。

白话版

CAP 定理像挑选租房：

• 离地铁近（C — 一致性，Consistency）
• 价格便宜（A — 可用性，Availability）
• 装修好（P — 分区容错性，Partition Tolerance）

你最多只能选两个。 离地铁近又价格便宜，装修就别指望了；价格便宜又装修好，就得忍受通勤时间。

在分布式系统中，这三个特性遇到”网络分区”（P — 网络断开）时，你必须二选一：

• CP 架构：保一致，舍可用。网络断了？那就停止服务，确保所有人读到一致的数据。
• AP 架构：保可用，舍一致。网络断了？服务继续运行，但不同分区可能读到不同的数据，等网络恢复后再同步。

三个特性详解

C — 一致性（Consistency）

所有节点在同一时刻看到的数据是相同的。

客户端写操作 ➔ 节点 A (写入成功)
                 ↓ (同步复制)
               节点 B (写入成功)

客户端读操作 ➔ 节点 B ➔ 读到最新数据 ✅

A — 可用性（Availability）

每个非故障节点发起的请求都能收到非错误的响应（但不保证读到最新数据）。

客户端写操作 ➔ 节点 A (写入成功)
               × (网络挂了无法同步)
客户端读操作 ➔ 节点 B ➔ 读到旧数据（但仍正常响应 200，保证可用）✅

P — 分区容错性（Partition Tolerance）

当节点之间发生网络通信故障（网络分区）时，系统仍能继续对外提供服务。

注意：在分布式网络中，硬件故障、网络抖动不可避免，因此 P 是必选项！真正的选择是在 P 前提下的 CP 或 AP。

CP 架构 vs AP 架构典型对比

模式	特性	典型代表系统	适用场景
CP (一致性 + 分区容错)	发生网络分区时拒绝对外响应或抛错，确保数据严格一致	ZooKeeper, HBase, Consul	银行转账、分布式锁、元数据中心
AP (可用性 + 分区容错)	发生网络分区时继续响应，数据可能短期不一致（最终一致）	Eureka, Cassandra, DynamoDB	社交朋友圈、视频点播、商品浏览

小结

CAP 定理告诫我们：不存在完美无缺的分布式系统。架构设计不是追求全能，而是在业务场景约束下做最合适的折衷与取舍。