前言

在现代分布式系统中，系统经常部署在多个地理位置、跨多个节点，网络延迟、故障和节点不一致成为常态。如何在这种复杂环境下权衡一致性与可用性？CAP 定理给出了明确的理论指导。

定义

Wiki 定义如下：

In theoretical computer science, the CAP theorem states that it is impossible for a distributed data store to simultaneously provide more than two out of the following three guarantees: Consistency, Availability, and Partition Tolerance.

简而言之：

CAP 定理指出：在一个分布式系统中，Consistency（一致性）、Availability（可用性）和 Partition Tolerance（分区容忍性）三者不能同时完全满足，最多只能满足其中两项。

工作原理

一句话： 在网络分区发生时，系统必须在“一致性”和“可用性”之间做出选择。

CAP 三要素解释如下：

  • C - Consistency（一致性） 所有节点在同一时间看到的数据完全一致。

  • A - Availability（可用性） 每个请求都能在有限时间内获得响应（成功或失败）。

  • P - Partition Tolerance（分区容忍性） 系统在部分网络故障（如节点间断连）时仍能继续提供服务。

当网络正常时，系统可能同时满足 C 和 A。但一旦发生分区（Partition），必须放弃 C 或 A 之一。

属性与指标

在实际系统设计中，CAP 影响的关键属性有：

  1. 可预测性 用户是否总能读取最新数据？

  2. 可用性 故障发生时系统还能否响应请求？

  3. 故障容忍度 系统面对网络不通、节点宕机时能否保持正常运行？

  4. 响应延迟 CAP 选择对系统延迟有直接影响。

  5. 最终一致性 有些系统通过牺牲强一致性，转而选择 eventual consistency。

类型

根据 CAP 三者的取舍，不同系统可大致分为以下几类：

CP 系统（强一致性 + 分区容忍）

特点：放弃高可用，一致性优先。

  • 常见系统：HBase、MongoDB（强一致配置）
  • 适用场景：银行系统、订单系统

AP 系统（高可用 + 分区容忍）

特点：牺牲一致性，但确保服务不挂。

  • 常见系统：Cassandra、Dynamo、CouchDB
  • 适用场景：社交、缓存、日志收集等对一致性要求不高场景

CA 系统（强一致性 + 高可用）

特点：不考虑网络分区（理论上不成立，非分布式或单节点系统）

  • 常见系统：传统关系型数据库（在单机部署下）
  • 适用场景：本地数据库、嵌入式系统

CAP 与程序关系

CAP 的设计理念决定了程序如何处理异常、重试以及写冲突等：

  • CP 系统中程序要更关注服务降级和容灾；
  • AP 系统中程序需设计好 conflict resolution；
  • 构建跨节点业务逻辑时必须显式处理因 CAP 限制导致的异步行为。

常见 CAP 应用系统

系统/数据库 所属类型 CAP 取舍
Cassandra AP 高可用 + 分区容忍
MongoDB CP 强一致 + 分区容忍
Zookeeper CP 强一致 + 分区容忍
Redis Sentinel AP 高可用 + 分区容忍
etcd / Consul CP 强一致 + 分区容忍
MySQL（主从） CA 非分布式时满足 CA

总结

CAP 定理是构建分布式系统的根基理论之一。理解 CAP 的三选二原则，不仅能帮助我们合理设计系统架构，也有助于我们在面对故障和扩展性问题时做出理性取舍。

记住一句话：没有完美系统，只有根据业务权衡后的合理选择。