分布式系统演进：从 CAP 到 PACELC 的架构思考

Tue, 19 May 2026 00:00:00 +0000

CAP 定理是分布式系统的「牛顿第一定律」——它定义了这个领域的基本约束。但在真实的工程实践中，CAP 定理过于粗粒度，以至于它无法指导我们在实际系统中做出正确的设计决策。我们需要一个更精细的模型。

CAP 定理的再理解

2000 年，Eric Brewer 提出 CAP 猜想；2002 年，Gilbert 和 Lynch 给出了形式化证明。CAP 定理告诉我们：

在一个分布式系统中，以下三个特性最多只能同时满足两个：

C (Consistency)  - 一致性：所有节点在同一时刻看到相同的数据
A (Availability) - 可用性：每个请求都能在合理时间内收到非错误响应
P (Partition Tolerance) - 分区容错：网络分区发生时系统仍能运行

大多数架构师对 CAP 的理解停留在「三选二」的层面。但这个理解有几个问题：

问题 1：P 不是一个可选项

在真实的分布式系统中，网络分区是必然会发生的事情——交换机故障、光缆被挖断、数据中心之间的网络抖动。所以 P 不是你可以「选择放弃」的特性，它是一个既定事实。

真正的选择是在 C 和 A 之间，而且这个选择只在分区发生时才有意义。

没有分区时：C 和 A 可以同时满足
发生分区时：必须在 C 和 A 之间选择

CP 系统：分区时拒绝服务，保证一致性
  例：ZooKeeper、etcd、HBase

AP 系统：分区时继续服务，可能返回过期数据
  例：Cassandra、DynamoDB、CouchDB

问题 2：CAP 是全局的，但需求是局部的

同一个系统中，不同的业务操作可能有不同的一致性需求：

电商系统的一致性需求：

操作 A：扣减库存
  → 需要强一致性（不能超卖）→ CP

操作 B：展示商品评价
  → 可以接受最终一致性（延迟几秒看到新评价无所谓）→ AP

操作 C：用户修改收货地址
  → 需要强一致性（改错了会寄错地方）→ CP

操作 D：商品浏览量计数
  → 可以接受最终一致性（少计几次没关系）→ AP

一个成熟的分布式系统不会在全局层面选择 CP 或 AP，而是在每个操作级别做精细的选择。

高可用 on 架构视界

分布式系统演进：从 CAP 到 PACELC 的架构思考

CAP 定理的再理解