Guide

Appearance

CAP 理论：C一致性、A可用性、P分区容错性 ​

凌晨 3 点，你被一个奇怪的线上报警惊醒：订单服务显示正常，但用户付款后订单状态一直是「待支付」。刷新页面没用，等了 5 分钟居然好了。

这不是 bug，这是 CAP 定理在「教育」你。

三选二？你被骗了很多年 ​

大多数教材会告诉你：CAP 理论意味着你只能同时满足三个特性中的两个。

这是错误的理解。

CAP 理论真正的意思是：在分布式系统遇到网络分区的情况下，你必须在一致性和可用性之间做出选择。

换句话说：CAP 三者中，P（分区容错性）是必然发生的，不是可选的。网络会断、机器会挂、交换机会有故障——在真实的分布式系统中，分区不是「如果发生」，而是「何时发生」。

所以真正的选择只有两个：

CP：分区时放弃可用性，保证一致性
AP：分区时放弃一致性，保证可用性

一致性（Consistency） ​

一致性指的是：任何一个读操作都能读到最近一次写入的结果。

就像你和女朋友共享一个日历——她在北京，你在上海，当你她在日历上添加了一个「纪念日」，你下一秒打开日历必须看到这个新增，否则你们就会因为「忘了」纪念日而吵架。

在分布式系统中，这意味着所有节点看到的数据必须一样。

可用性（Availability） ​

可用性指的是：每个请求都能在有限时间内得到响应，不管节点状态如何。

你打开一个网页，浏览器转圈超过 30 秒，你会骂娘。可用性就是要保证：就算系统忙、就算某个节点挂了，你的请求也不会石沉大海。

注意：可用性不保证返回的是最新数据，它只保证「有响应」。

分区容错性（Partition Tolerance） ​

分区容错性指的是：当网络分区发生时（节点之间无法通信），系统仍然能继续运转。

这里的「分区」是指：网络故障导致集群被分割成多个无法相互通信的子集。就像疫情期间，北京和上海各自封城，各自为战。

为什么 P 是必选项 ​

你可能会想：我能不能构建一个既不发生分区、也不需要做选择的系统？

答案是：不能。

在分布式系统中，节点分布在不同的机器上，通过网络通信。只要有网络，就有可能出现延迟、丢包、甚至中断。物理定律决定了：你无法控制网络的可靠性。

因此，在设计分布式系统时，你必须假设分区会发生。CAP 理论告诉你的是：当它发生时，你怎么办？

CP vs AP：真实系统的选择 ​

CP 系统代表：ZooKeeper、etcd ​

ZooKeeper 是一个典型的 CP 系统。当网络分区发生时，如果 Leader 所在的分区节点数不足半数，整个 ZooKeeper 集群会停止服务，直到分区恢复。

这意味着：牺牲了可用性，但保证了你读到的数据一定是最新的。

java
/**
 * ZooKeeper 的读写模型体现了 CP 特性
 * 写操作需要 Leader 处理，保证一致性
 * 读操作可以由任意节点处理，但可能读到过期数据（通过 sync() 可强制读取最新）
 */
public class ZooKeeperModel {
    /**
     * ZooKeeper 的 ZAB 协议保证了写操作的全局顺序
     * 在 Leader 选举期间，集群不可用——这是 CP 的代价
     */
    public static final String MODEL = "CP: Consistent during partition";
}

AP 系统代表：Cassandra、DynamoDB ​

Cassandra 是一个典型的 AP 系统。当网络分区发生时，每个节点继续服务本地客户端，写入操作被记录在本地，分区恢复后再同步。

这意味着：牺牲了强一致性，但你随时都能读写数据。

DynamoDB 的读写模型：
- 写入：本地写入，立即返回（可用性优先）
- 读取：可能返回过期数据（最终一致）
- 冲突解决：向量时钟或最后写入者获胜

同一个系统能否同时做到 CP 和 AP？ ​

这是个好问题。答案是：可以，但这取决于你从什么角度看待「一致性」和「可用性」。

方法一：数据分级 ​

系统中不同数据对一致性和可用性的要求不同：

java
public class DataClassification {
    // 强一致性数据：用户余额、订单状态（CP）
    Map<String, Object> criticalData = new ConcurrentHashMap<>();
    
    // 弱一致性数据：用户头像、个性化推荐（AP）
    Map<String, Object> nonCriticalData = new ConcurrentHashMap<>();
    
    // 不同数据采用不同策略，这就是混合策略
}

比如电商系统：用户余额必须严格一致（CP），但商品浏览量可以用最终一致性（AP）。

方法二：读写分离 ​

java
/**
 * 主从架构下的读写分离策略
 * 写操作走主库（强一致）——CP
 * 读操作走从库（可能过期）——AP
 */
public class ReadWriteSeparation {
    /**
     * 同步双写：写成功 = 两个节点都写入成功
     * 优点：强一致
     * 缺点：延迟高，分区时不可用
     */
    public void syncWrite(Object data) {
        // 同步写入所有节点
    }
    
    /**
     * 异步复制：写入主节点后立即返回
     * 优点：延迟低，可用性高
     * 缺点：可能读到旧数据
     */
    public void asyncWrite(Object data) {
        // 异步复制到从节点
    }
}

面试高频追问方向 ​

追问 1：为什么 Redis Cluster 选择 AP 而不是 CP？

Redis Cluster 采用了异步复制 + 自动故障转移的 AP 策略。原因：Redis 定位是缓存系统，对数据丢失有一定容忍度，更强调可用性。金融场景下，用 Codis 或 Redis Sentinel（提供更强的配置一致性）。

追问 2：Eureka 和 ZooKeeper 在 CAP 取舍上有什么不同？

Eureka 是 AP 系统，服务注册信息可以不一致，但服务发现始终可用；ZooKeeper 是 CP 系统，分区期间服务注册可能不可用，但数据一致。

追问 3：分区恢复后，如何修复数据一致性？

需要设计补偿机制——Cassandra 使用反熵（Anti-Entropy）修复，ZooKeeper 使用 zab 协议的恢复模式同步数据。

总结 ​

CAP 理论不是让你死记硬背的考试题，它是分布式系统设计的第一性原理：

  1. 网络分区不可避免，P 必须考虑
  2. 分区发生时，你必须在 C 和 A 之间选择
  3. 选择没有对错，只有场景适配
  4. 现实中，大多数系统采用混合策略

"CAP 定理教给我们的不是「能选什么」，而是「必须放弃什么」。理解这一点，你才能设计出真正可靠的分布式系统。"

基于 VitePress 构建

Copyright © 2025-2026 Guide