CAP 理论 - 分布式系统的核心约束

三种分布式系统类型

由于网络分区必然发生，分布式系统只能选择实现其中两种特性

CA 系统

一致性 + 可用性

假设网络永远不会断开。不追求分区容错，在没有分区发生的情况下，同时保证一致性和可用性。 现实分布式系统中不存在，因为分区必然发生。

传统单机数据库 PostgreSQL (单节点)

CP 系统

一致性 + 分区容错

遇到分区时，拒绝请求以保证一致性。宁可返回错误，也绝不错写数据。适合对数据准确性要求极高的场景，如金融、分布式锁、协调服务。

Redis Cluster ZooKeeper Etcd HBase MongoDB (多数派模式)

AP 系统

可用性 + 分区容错

遇到分区时，继续服务但可能返回旧数据。保证系统可用，但会短暂不一致。适合对可用性要求高、能容忍最终一致的场景，如社交Feed、缓存、CDN。

Cassandra DynamoDB Riak CouchDB Redis Sentinel

📡 网络分区发生时会发生什么？

假设 Node A 和 Node B 之间网络断开...

CP 策略：牺牲可用性

Node A

Primary X = 100

Node B

Replica X = ?

❌ 写入请求被拒绝
"无法确认副本同步"

⚡

网络断开

AP 策略：牺牲一致性

Node A

Primary X = 100

Node B

Replica X = 50

✓ 写入请求被接受
"但两节点数据短暂不一致"

CP - 强一致性，但可能不可用

AP - 高可用，但可能返回旧数据

💡 核心洞察

CAP 并不意味着"永远只能选择两个"。

在没有网络分区的正常情况下，可以同时保证一致性和可用性。
CAP 理论描述的是当分区发生时的权衡选择。

现代分布式系统的设计哲学：选择 AP + 最终一致性，通过其他机制（向量时钟、版本向量、Gossip 协议等）
在分区恢复后将数据最终同步一致。

📊 CAP 三特性详细对比

特性	定义	核心问题	典型场景
C 一致性	所有节点在同一时刻看到相同的数据	分布式事务、共识算法	银行转账、分布式锁、配置中心
A 可用性	每个请求都能在有限时间内得到响应	故障检测、熔断降级	电商详情页、社交Feed、内容推荐
P 分区容错	系统能容忍节点间的网络断开	网络不可靠、节点故障	所有真实分布式系统