1.1 一致性（Consistency）#

所有节点在同一时刻看到相同的数据。等价于线性一致性（Linearizability）：一个写操作完成后，任何后续读操作都能读到该值。

1
Client A → Write(x=1) → Node1
2
Client B → Read(x)    → Node2 → 返回 1（而非旧值 0）

注意：CAP 中的 C 指的是强一致性，而非数据库领域的 ACID 一致性，两者含义不同。

1.2 可用性（Availability）#

每一个非故障节点对请求都能在合理时间内返回非错误的响应，不保证数据是最新的，但系统不会拒绝服务。

1
Client → Request → Node（即使数据过期）→ 返回响应（可能过期）

可用性强调的是”系统不拒绝服务”，而非”数据一定最新”。

1.3 分区容错性（Partition Tolerance）#

系统在网络分区（Network Partition）的情况下仍能继续运作。网络分区指节点间通信失败，可能由网络故障、交换机宕机等引起。

在分布式系统中，网络分区不是”是否发生”的问题，而是”何时发生”的问题，因此分区容错性通常是必选项。

3.1 CP 系统：优先一致性#

典型代表：ZooKeeper、etcd、HBase

适用场景：金融交易、库存扣减等对数据准确性要求极高的业务。

1
用户下单扣库存 → 主节点写入 → 等待多数节点确认 → 返回成功
2
                              ↓
3
                     如果多数节点不可达 → 返回错误（牺牲可用性）

3.2 AP 系统：优先可用性#

典型代表：Cassandra、DynamoDB（默认配置）、Eureka

适用场景：社交动态、商品推荐等对实时性要求不高但要求高可用的业务。

1
用户发帖 → 写入本地节点 → 立即返回成功 → 异步同步到其他节点
2
                                          ↓
3
                                  读取时可能拿到过期数据

3.3 混合策略#

多数现代系统在不同操作上采用不同策略：

4.1 BASE 理论#

BASE 是对 AP 系统的实践总结：

• Basically Available（基本可用）：系统在故障时允许响应时间增加或功能降级
• Soft State（软状态）：允许数据存在中间状态
• Eventually Consistent（最终一致性）：数据副本最终会收敛到一致状态

4.2 PACELC 定理#

PACELC 对 CAP 进行了扩展：即使没有分区（P），延迟（L）和一致性（C）之间也存在权衡。

1
如果分区（P）发生：在可用性（A）和一致性（C）之间选择
2
否则（E）：在延迟（L）和一致性（C）之间选择

这意味着系统设计不仅在故障时需要取舍，正常运行时也需要在响应速度和数据一致性之间权衡。

5.1 “CAP 说三者永远不能同时满足”#

不准确。CAP 说的是在网络分区发生时，C 和 A 无法同时满足。正常运行时，系统可以同时提供一致性和可用性。

5.2 “选择了 CP 就完全不可用”#

CP 系统在分区时只是对涉及不一致数据的请求返回错误，其他请求仍然正常响应。ZooKeeper 在 Leader 选举期间并非完全不可用，只是写请求被拒绝。

5.3 “AP 系统不需要关心一致性”#

AP 系统牺牲的是强一致性，但仍需保证最终一致性。DynamoDB 提供了可调一致性模型，允许在读操作时选择强一致性读或最终一致性读。