分布式系统的所有问题，最后都能追溯到 CAP 定理。所有分布式方案的取舍，最后都落在 BASE 理论。本篇把这两块理论基石讲透——它们是后续所有分布式事务、注册中心、配置中心选型的底层依据。
一、CAP 定理
1.1 三个字母
CAP 是三个单词的首字母：
| 字母 | 全称 | 含义 |
|---|---|---|
| C | Consistency | 一致性 |
| A | Availability | 可用性 |
| P | Partition tolerance | 分区容错性 |
1.2 经典场景：G1 / G2 双节点
图中两个服务端节点 G1、G2，各持有一份数据副本；client 同时与两个节点通信。
1.3 三个特性的定义
C —— 一致性
当 client 发起一个写请求到 G1 节点，G1 数据修改后，为了使 client 从 G2 读取到的数据也是一致的，则需要 G1 区数据同步到 G2 区——这就是数据一致性。
A —— 可用性
当 client 连接到 G1 或者 G2 时，都能被服务获取到数据——即可用性。
P —— 分区容错性
大多数分布式系统分布在多个子网络，每个子网络就是一个区（partition）。分区容错的意思是：
- 区间通信可能失败，无法保证两台服务器之间一直可以通信
- 系统设计时是必须考虑的，无法避免
而当分区通信故障时：
- client 操作 G1 写入的数据，不能及时同步到 G2 分区
- 这时就要在 C 和 A 之间做出取舍
- 如果需要一致性 → 等待 G1、G2 同步完毕再提供服务 → 违背可用性
- 如果不等同步完毕，G2 就对外提供服务 → 数据一致性无法保证
1.4 三选二，其实只有 CP vs AP
关键认知：分布式系统P 是必然发生的——网络分区是物理事实，无法避免。所以实际工程中，CAP 不是「三选二」，而是「P 必选 + C/A 二选一」。
| 取舍 | 含义 | 代价 |
|---|---|---|
| CP | 分区时拒绝服务，等到数据一致再恢复 | 牺牲可用性 |
| AP | 分区时继续服务，允许数据不一致 | 牺牲一致性 |
| 假设不发生分区——单机系统才成立 | 不是分布式 |
二、一致性分级
一般来讲，我们将一致性分为三类：
2.1 强一致性（Strong Consistency）
保证写操作完成后，任何后续访问都能读到更新后的值。
典型实现：两阶段提交（2PC）、线性一致性（Linearizability）。
代价：需要协调 + 锁，性能差。
2.2 弱一致性（Weak Consistency）
写操作完成后，系统不能保证后续的访问都能读到更新后的值。
典型场景：语音通话、实时游戏位置同步——不要求所有人同时刻看到同一状态。
2.3 最终一致性（Eventual Consistency）
介于强弱一致性中间，保证如果对某个对象没有新的写操作了，最终所有后续访问都能读到相同的最近更新的值。
典型实现：DNS、MySQL 主从异步复制、Cassandra。
最终一致性是 BASE 理论的基石——互联网业务 90% 的一致性需求，都靠最终一致性满足。
2.4 三级对比
| 级别 | 读保证 | 性能 | 适用 |
|---|---|---|---|
| 强一致 | 写完立即可读 | ❌ 差 | 金融账户、库存扣减 |
| 弱一致 | 不保证 | ✅ 最好 | 实时音视频、游戏 |
| 最终一致 | 经过一段时间后可读 | ✅ 好 | 大多数互联网业务 |
三、BASE 理论
BASE 是 CAP 理论的延伸，核心思想是：即使无法做到强一致性，也要达到最终一致性。
BASE 是三个短语的缩写：
3.1 BA —— Basically Available（基本可用性）
分布式系统出现故障时，允许损失部分可用性，保证核心可用。
典型例子：
- 电商大促：商品详情页正常，但「退款」按钮暂时关闭
- 搜索降级：搜索服务压力过大时，从精准匹配降级为模糊匹配
- 响应时间放慢：平时 100ms，故障时允许 3s
3.2 S —— Soft State（软状态）
允许系统出现中间状态，中间状态不会影响系统整体可用性。
例如：
- 分布式存储中相同数据有三份副本，不同节点间同步延长就是软状态的体现
- 订单状态「处理中」「出票中」——不是终态，但系统依然可用
3.3 E —— Eventual Consistency（最终一致性）
所有系统副本经过一段时间后，最终达到一致的状态。
这一条是 BASE 的核心——也是前面讲的「最终一致性」一致性级别。
软状态是「过程」，最终一致性是「结果」。BASE 的本质：接受过程中的不一致，换取系统的可用性，并保证最终达成一致。
四、实战选型：注册中心三巨头
理论讲完，看实战。注册中心是最经典的 CAP 选型案例：
| 注册中心 | CAP 取舍 | 说明 |
|---|---|---|
| ZooKeeper | CP | 写入要半数以上节点同意，节点多时性能差；主节点宕机期间不可用（选举期间） |
| Eureka | AP | 节点间异步复制，任一节点都可读写；分区时各自保护，可用性极高 |
| Nacos | AP + CP（可切换） | 默认 AP；配置中心场景切 CP（一致性更重要） |
| etcd | CP | Raft 协议，Kubernetes 的选择 |
| Consul | CP | Raft 协议，带健康检查 |
4.1 为什么注册中心选 AP
注册中心的核心场景是「服务发现」——consumer 找 provider。读到稍微旧一点的实例列表（比如某节点刚下线但列表还没更新）不是大问题，大不了请求失败重试一次。
但如果注册中心选 CP，节点选举期间整个注册中心不可用——这时新服务注册不了、下线通知不到，故障扩散比读到脏数据严重得多。
这也是为什么 Spring Cloud 生态早期默认用 Eureka（AP），而 Dubbo 生态用 ZK（CP）——业务诉求不同，CAP 取舍不同。
4.2 为什么配置中心选 CP
配置中心的核心场景是「配置分发」——所有节点读到同一份配置。配置不一致会导致代码行为分裂，比短暂不可用严重。
所以 Nacos 区分了两套模式：服务发现走 AP，配置管理走 CP——按业务诉求灵活切换。
五、CP 和 AP 的工程信号
判断一个分布式系统是 CP 还是 AP，看两点：
| 信号 | CP 系统 | AP 系统 |
|---|---|---|
| 写入需要 Quorum | 写要半数以上同意 | 任意单节点可写 |
| 故障时行为 | 拒绝服务 / 等待选举 | 继续服务，接受不一致 |
举几个例子：
| 系统 | 类型 | 信号 |
|---|---|---|
| ZooKeeper | CP | 写要 leader + 半数 follower 同意；leader 宕机选举期间不可用 |
| Redis 主从 | 弱 AP | 主从异步复制；主节点宕机有数据丢失窗口 |
| MySQL 主从（异步） | AP | 从库延迟常见；主库宕机有丢数据风险 |
| Kafka（acks=all） | 偏 CP | 等所有 ISR 副本确认；leader 宕机从 ISR 选新 leader |
| Cassandra | 可调 | 可配置 consistency level（ONE/QUORUM/ALL） |
Kafka 的有趣之处：它不是严格的 CP 或 AP，而是「可调一致性」——通过
acks参数（0/1/all）和min.insync.replicas调节。详见 Kafka（上）：特性、应用场景与消息传递保障。
六、BASE 的落地：最终一致性方案矩阵
BASE 理论怎么落地？就是分布式事务五种方案的取舍依据：
| 业务诉求 | 一致性级别 | 推荐方案 |
|---|---|---|
| 资金、库存（必须准） | 强一致 | XA / Seata AT |
| 高并发资金（可短暂不一致） | 最终一致（隔离好） | TCC |
| 业务链路清晰 | 最终一致 | 消息驱动 / 本地消息表 |
| 长流程业务 | 最终一致 | Saga |
→ 这五种方案的具体对比，见 分布式事务五种方案：消息驱动 / XA / TCC / 本地消息表 / Saga。
七、常见误区
7.1 「CAP 三选二，所以可以选 CA」
❌ 错。分布式系统P 必然存在，不能选「CA 而放弃 P」——「放弃 P」等同于「假设网络永不分区」，只有单机系统成立。
7.2 「AP 系统就不一致了」
❌ 误解。AP 系统是分区期间允许不一致；无分区时，AP 系统依然尽量保持一致（通过异步复制 + 读修复）。
7.3 「最终一致性 = 不一致」
❌ 错。最终一致性的契约是「如果没有新的写操作，最终所有读都会返回最后写入的值」。「最终」是有界的——通常秒级。
八、小结
| 理论 | 核心 | 一句话 |
|---|---|---|
| CAP | 分布式三选二，P 必选 | 工程上是 CP vs AP 二选一 |
| 一致性分级 | 强 / 弱 / 最终 | 互联网业务 90% 用最终一致 |
| BASE | CAP 的工程化延伸 | 接受中间状态，保证最终一致 |
CAP 和 BASE 是分布式系统的「宪法」——所有具体的分布式方案（事务、注册中心、配置中心、数据库复制）都是对这两条宪法的具体解释和应用。理解了这两条，后面的所有选型题都有据可依。
现代视角补一句（2026）：CAP 定理自 2000 年 Brewer 提出以来，到 2026 年一字未改——这是计算机科学中少有的「经久耐用」的定理。变的只是工程实现：PACELC 定理（CAP 的扩展，无分区时还要看 L 延迟 vs C 一致性）成了新共识，CRDT 数据结构（无冲突复制数据类型）让 AP 系统也能自动收敛——但这些都建立在 CAP 之上，没有颠覆它。
下一篇 分布式事务五种方案 是 BASE 理论的完整实战——看 5 种方案各自如何在 C 和 A 之间取舍。