CAP原则
CAP 原则详解
一、什么是 CAP 原则
CAP 定理（Consistency-Availability-Partition tolerance Theorem）是分布式系统设计的核心理论，由 Eric Brewer 在 2000 年提出，后由 Seth Gilbert 和 Nancy Lynch 在 2002 年严格证明。
CAP 定理指出：分布式系统不可能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三个特性，最多只能同时满足其中两个。
二、三个核心特性
2.1 一致性（Consistency）
所有节点在同一时刻看到相同的数据，即读写操作是原子的。当一个节点的数据更新后，其他所有节点都必须同步更新后，才允许读取。
2.2 可用性（Availability）
每个请求都能在有限时间内获得响应，系统始终可用。无论系统内部状态如何，都能对用户的请求作出响应。
2.3 分区容错性（Partition tolerance）
网络分区发生时（节点间无法通信），系统仍能继续运行。由于网络延迟、丢包、节点故障等原因，分区是分布式系统中不可避免的。
三、三者不可兼得的原因
分布式系统中，网络分区是必然会发生的。当分区发生时：
- 如果选择一致性：必须等待分区恢复，期间系统不可用（牺牲可用性）
- 如果选择可用性：分区两侧各自处理请求，可能导致数据不一致（牺牲一致性）
在实际分布式系统中，分区容错性（P）是必须保证的基本前提，因此实际的取舍通常是在 C 和 A 之间做选择。
四、三种组合模型
4.1 CA 模型（Consistency + Availability）
核心思想：放弃分区容错性，确保强一致性和高可用性。
实际含义：分区不可避免，CA 模型指的是分区发生后，各子系统内部仍保持 CA，分区恢复后再进行数据同步。
典型应用：
| 应用 | 说明 |
|---|---|
| 集群数据库 | MySQL/PostgreSQL 主从复制（同步复制模式） |
| xFS 文件系统 | 分布式文件系统的强一致性实现 |
| 单体应用 | 单节点部署，天然满足 CA |
4.2 CP 模型（Consistency + Partition tolerance）
核心思想：牺牲可用性，保证数据一致性和分区容错性。
典型场景：网络分区时，系统拒绝请求直到数据一致，因此可能出现短暂不可用。
典型应用：
| 应用 | 说明 |
|---|---|
| 分布式数据库 | MongoDB（副本集）、CockroachDB |
| 分布式锁 | Redis Redlock、ZooKeeper |
| 分布式协调服务 | ZooKeeper |
ZooKeeper 为何是 CP？
- Leader 选举期间，集群对外不可用（牺牲可用性）
- 数据写入必须同步到过半节点才返回成功（保证一致性）
4.3 AP 模型（Availability + Partition tolerance）
核心思想：牺牲强一致性，保证高可用性和分区容错性。
典型场景：分区发生时，各节点独立提供服务，接受可能不一致的数据，后续通过最终一致性同步。
典型应用：
| 应用 | 说明 |
|---|---|
| Web 缓存 | CDN、Redis 集群 |
| DNS | 域名解析系统 |
| NoSQL 数据库 | Cassandra、DynamoDB |
| 消息队列 | Kafka、RabbitMQ |
Eureka 为何是 AP？
- 即使部分节点不可用，其他节点仍可提供注册/发现服务
- 客户端可以缓存服务列表，即使 Eureka 集群全部宕机也能工作
- 数据可能短暂不一致，但最终会同步
五、注册中心对比：ZooKeeper vs Eureka vs Nacos
| 特性 | ZooKeeper | Eureka | Nacos |
|---|---|---|---|
| CAP 模型 | CP | AP | CP/AP 可切换 |
| 一致性保证 | 强一致性 | 最终一致性 | 可配置 |
| 可用性 | 选举期间不可用 | 始终可用 | 高可用 |
| 适用场景 | 数据一致性要求高 | 服务发现为主 | 灵活适配 |
Nacos 的 CAP 切换机制：
# Nacos 默认 AP 模式
# 通过配置切换为 CP 模式
nacos.core.protocol.default-json=true
六、CAP 选择策略流程图
CA 模型：仅适用于单体应用或单机系统，不考虑网络分区，天然满足强一致性和高可用性。
七、CAP 的局限性与延伸
7.1 CAP 的局限性
CAP 定理描述的是极端情况下的理论模型，实际系统中可以通过以下方式缓解：
- 分区恢复后的数据同步：在分区恢复时进行数据 reconciliation
- 不同场景的差异化策略：对关键业务采用 CP，非关键业务采用 AP
- BASE 理论：牺牲强一致性，追求基本可用、软状态、最终一致性
7.2 BASE 理论
BASE 是对 CAP 中 AP 模型的延伸，包括：
- Basically Available（基本可用）：系统出现故障时，允许损失部分可用性
- Soft state（软状态）：允许系统存在中间状态，不影响整体可用性
- Eventually consistent（最终一致性）：数据在经过一段时间后最终达到一致
八、总结
| 模型 | 适用场景 | 核心取舍 |
|---|---|---|
| CA | 单体应用、小集群 | 不考虑分区，追求完美一致性 |
| CP | 金融交易、分布式锁 | 数据安全优先，允许短暂不可用 |
| AP | 互联网服务、缓存 | 用户体验优先，接受最终一致 |
一句话原则：绝大多数分布式系统选择 AP，关键业务场景（如支付）采用 CP。
浙公网安备 33010602011771号