前言

CAP 定理揭示了分布式系统在「一致性（Consistency）」「可用性（Availability）」与「分区容忍性（Partition Tolerance）」之间的取舍。然而，现实系统中不仅要考虑网络分区，还要在正常情况下权衡延迟与一致性。为此，PACELC 定理应运而生，作为对 CAP 的自然扩展。

定义

PACELC 定理由 Daniel Abadi 提出，其原始论文定义如下：

If there is a Partition (P), then a system must choose between Availability (A) and Consistency (C); Else (E), when the system is running normally (no partition), it must choose between Latency (L) and Consistency (C).

简而言之：

PACELC = 如果发生分区（P），则系统要在可用性（A）和一致性（C）之间取舍；否则（E），在没有分区时，要在延迟（L）和一致性（C）之间取舍。

工作原理

一句话总结： PACELC = CAP + 正常情况下的延迟与一致性权衡。

举个例子：

  • 在分区时：必须选 A or C（即 CAP）
  • 在正常时：必须选 L or C（即低延迟或强一致）

例如：

  • DynamoDB：PA/EL（分区选 A，正常选低延迟）
  • Spanner：PC/EC（始终优先保证一致性）

属性与指标

PACELC 带来的核心指标有：

  1. 延迟（Latency）

    • 多副本同步所需的网络 RTT 数

  2. 强一致性（Strong Consistency）

    • 是否保证读写最新数据（linearizability）

  3. 最终一致性（Eventual Consistency）

    • 是否接受短时间的数据不一致

  4. 吞吐量（Throughput）

    • 系统在不同策略下的稳定写入/读取能力

  5. 可用性（Availability）

    • 是否能在任意节点故障后仍提供服务

类型

按照 PACELC 的两个维度（分区时、正常时）进行分类：

类型 分区时选择 正常时选择 示例系统
PA/EL 可用性 低延迟 DynamoDB, Cassandra
PC/EC 一致性 一致性 Google Spanner, Zookeeper
PA/EC 可用性 一致性 MongoDB (可配置)
PC/EL 一致性 低延迟 较少见，需定制优化

PACELC 与程序关系

PACELC 指导开发者在设计系统时要：

  • 显式处理正常与异常状态的行为差异；
  • 选择合适的复制机制（同步 vs 异步）；
  • 针对业务读写特点，定制 consistency level（如 quorum 机制）；
  • 考虑 eventual consistency 带来的冲突合并策略（conflict resolution）。

常见系统对照

系统/数据库 PACELC 类型 特性说明
Cassandra PA/EL 高可用、低延迟，最终一致
DynamoDB PA/EL 高可用、低延迟，强/弱一致可选
MongoDB 可配型 PA/EC 默认行为，可调写入策略
Spanner PC/EC 强一致，基于全球时钟同步
Zookeeper PC/EC 强一致，适合协调类任务

总结

CAP 定理聚焦于网络分区情况下的权衡，而 PACELC 更进一步，将**正常情况（Else）**下的权衡纳入视野，是更完整的系统设计理论。

PACELC 告诉我们：在构建分布式系统时，即使没有分区，延迟与一致性之间的权衡依然存在。

理解 PACELC，有助于我们根据业务需求定制系统架构，做出明确、理性的技术选择。