概述

CAP定理（又称Brewer定理）是分布式系统设计中最重要的理论基础之一。它由加州大学伯克利分校的Eric Brewer教授在2000年提出，并于2002年由Seth Gilbert和Nancy Lynch正式证明。CAP定理指出：一个分布式系统不可能同时满足一致性(Consistency)、可用性(Availability)和分区容错性(Partition Tolerance)这三个基本需求，最多只能同时满足其中两个。

三个核心属性

一致性（Consistency）

一致性是指所有节点在同一时刻看到的数据是一致的。更严格地说，对于任何读操作，要么返回最近一次写操作的结果，要么返回错误。这里的一致性是指线性一致性（Linearizability），是最强的一致性模型。

// 一致性示例：写入后立即读取，必须返回最新值
public class ConsistencyExample {
    // 在 CP 系统中，以下操作保证一致性
    public void demonstrateConsistency() {
        // 客户端A写入
        kvStore.put("key", "value_v2");  // 写入成功后返回

        // 客户端B立即读取（即使在不同节点）
        String result = kvStore.get("key");
        // result 必须是 "value_v2"，不可能是旧值 "value_v1"
        assert result.equals("value_v2");
    }
}

可用性（Availability）

可用性要求每个非故障节点对于每个请求都必须在合理时间内返回有效响应（非错误和非超时）。注意，这里不要求返回的是最新的数据。

分区容错性（Partition Tolerance）

分区容错性要求系统在网络分区（部分节点之间的通信中断）的情况下仍能继续运行。在实际的分布式环境中，网络分区是不可避免的，因此P通常是必须保证的。

为什么只能三选二

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

CP系统（牺牲可用性）

选择一致性和分区容错性的系统，在网络分区时会拒绝服务，直到分区恢复。

典型系统：

• ZooKeeper：Leader选举期间不可用；少数派节点无法服务写请求
• etcd：基于Raft协议，需要多数派节点才能提交写入
• HBase：RegionServer故障时对应Region短暂不可用

// ZooKeeper CP行为示例
public class ZookeeperCPExample {
    public void writeData(ZooKeeper zk, String path, byte[] data) {
        try {
            // ZooKeeper要求Leader处理写请求
            // 如果与Leader的连接断开，写操作会失败
            zk.setData(path, data, -1);
        } catch (KeeperException.ConnectionLossException e) {
            // 网络分区时，客户端可能无法连接到Leader
            // 系统选择牺牲可用性来保证一致性
            log.error("Connection lost, cannot guarantee consistency", e);
            throw new ServiceUnavailableException("ZooKeeper partition detected");
        }
    }
}

AP系统（牺牲一致性）

选择可用性和分区容错性的系统，在网络分区时仍提供服务，但可能返回过期数据。

典型系统：

• Cassandra：可调节一致性级别，默认允许最终一致
• DynamoDB：最终一致性读取延迟低
• CouchDB：多主复制，冲突后合并

// Cassandra AP行为示例
public class CassandraAPExample {
    public void configureConsistency() {
        // ONE：只需一个副本响应即可（高可用，低一致性）
        Statement stmt = QueryBuilder.select().from("users")
            .where(eq("id", userId));
        stmt.setConsistencyLevel(ConsistencyLevel.ONE);

        // QUORUM：需要多数副本响应（平衡可用性和一致性）
        stmt.setConsistencyLevel(ConsistencyLevel.QUORUM);

        // ALL：所有副本响应（高一致性，低可用性）
        stmt.setConsistencyLevel(ConsistencyLevel.ALL);
    }
}

CA系统

在分布式环境中，网络分区不可避免，因此严格意义上CA系统不存在于分布式场景。传统的单机关系型数据库（如单节点MySQL、PostgreSQL）可视为CA系统。

PACELC扩展

Daniel Abadi在2012年提出了PACELC定理，对CAP进行了扩展：

如果存在分区（P），系统在可用性（A）和一致性（C）之间选择；否则（E, Else），系统在延迟（L）和一致性（C）之间选择。

系统	P时选择	E时选择	PACELC分类
ZooKeeper	PC	EC	PC/EC
Cassandra	PA	EL	PA/EL
MongoDB	PA (默认)	EC	PA/EC
DynamoDB	PA	EL	PA/EL
PNUTS (Yahoo)	PA	EC	PA/EC

可调一致性的MongoDB示例

MongoDB是一个很好的示例，展示了如何在CP和AP之间灵活切换：

// MongoDB可调一致性
const MongoClient = require('mongodb').MongoClient;

async function writeWithConcern(db) {
  const collection = db.collection('orders');

  // 写关注(Write Concern)控制一致性级别
  // w:1 - 只需primary确认（类似AP）
  await collection.insertOne(
    { orderId: '001', status: 'created' },
    { writeConcern: { w: 1 } }
  );

  // w:"majority" - 需要多数节点确认（类似CP）
  await collection.insertOne(
    { orderId: '002', status: 'created' },
    { writeConcern: { w: 'majority', wtimeout: 5000 } }
  );
}

async function readWithPreference(db) {
  const collection = db.collection('orders');

  // 读偏好(Read Preference)影响可用性
  // primary - 只从主节点读（强一致性）
  await collection.find({}).readPref('primary').toArray();

  // secondaryPreferred - 优先从从节点读（高可用，可能读到旧数据）
  await collection.find({}).readPref('secondaryPreferred').toArray();
}

实际系统的CAP选择对比

系统	CAP分类	一致性模型	说明
ZooKeeper	CP	线性一致性	Leader故障时短暂不可用
etcd	CP	线性一致性	Raft协议，多数派写入
Consul	CP	强一致性	基于Raft的服务发现
Redis Sentinel	CP	最终一致性	主从切换期间不可用
Cassandra	AP	可调一致性	默认最终一致性
DynamoDB	AP	最终一致性	支持强一致性读（单区域）
CouchDB	AP	最终一致性	多主复制
MongoDB	可调	可调一致性	通过writeConcern/readPreference调节

设计建议

在实际系统设计中，不应教条地套用CAP定理，而应该根据业务场景灵活选择：

核心原则：

1. 网络分区是现实：在分布式系统中，P是必须面对的，真正的选择是CP还是AP
2. 一致性是连续谱：从线性一致性到最终一致性之间有很多中间状态（因果一致性、会话一致性等）
3. 按操作级别配置：同一系统中不同操作可以有不同的一致性要求
4. CAP不是全部：还需考虑延迟、吞吐量、持久性等非功能需求

总结

CAP定理不是让我们做简单的二选一，而是提醒我们在设计分布式系统时需要理解各种权衡。现代分布式系统通常提供可调的一致性级别，让开发者根据具体业务场景在一致性和可用性之间做出最优选择。理解CAP定理的本质——以及PACELC等扩展理论——是成为合格的分布式系统架构师的必经之路。

贡献者

withesse

更新日志

2026/3/14 13:09

查看所有更新日志

• 9f6c2-feat: organize wiki content and refresh site setup于 2026/3/14

编辑此页