分布式知识梳理(2)
作者：没有四次元口袋的蓝胖
日期：2026-08-07
标签：Java, 分布式, CAP, BASE, 分布式理论
分布式系统两大理论基础。核心掌握：CAP 三选二、BASE 最终一致性思想。
一、CAP 定理
1.1 什么是 CAP？
CAP 是分布式系统设计时必须权衡的三个特性：
| 特性 | 英文 | 含义 |
|---|---|---|
| C | Consistency | 一致性：所有节点数据一致 |
| A | Availability | 可用性：每个请求都能得到响应 |
| P | Partition Tolerance | 分区容错性：网络分区时系统仍能运行 |
1.2 CAP 三选二
核心结论：分布式系统最多同时满足两个。
CAP = C + A + P（最多选两个）
实际选择：
- CP：一致性 + 分区容错（牺牲可用性）
- AP：可用性 + 分区容错（牺牲一致性）
- CA：一致性 + 可用性（牺牲分区容错，单机系统）1.3 为什么 P 必须保证？
分区容错性是分布式系统的基本要求。
网络分区（Partition）：集群中部分节点之间无法通信。
正常情况：
Node1 ←→ Node2 ←→ Node3（互相通信）
网络分区：
Node1 ←→ Node2 Node3
（Node1、Node2 与 Node3 之间无法通信）结论：分布式系统必然存在网络分区，所以 P 必须保证，只能在 C 和 A 之间选择。
1.4 CP vs AP
CP 系统（一致性 + 分区容错）
特点：网络分区时，为了保证一致性，部分请求会被拒绝。
代表：
-
Zookeeper
-
HBase
-
Redis Cluster（部分场景）
网络分区时：
客户端 → Node1（主节点，在分区 A）
客户端 → Node3（从节点，在分区 B）CP 系统行为：
Node1 正常处理请求
Node3 拒绝写入（保证一致性）
AP 系统（可用性 + 分区容错）
特点：网络分区时，为了保证可用性，允许返回旧数据。
代表：
-
Eureka
-
Cassandra
-
DynamoDB
网络分区时：
客户端 → Node1（主节点，在分区 A）
客户端 → Node3（从节点，在分区 B）AP 系统行为：
Node1 正常处理请求
Node3 也接受写入（但最终会同步）
1.5 CAP 对比表
| 维度 | CP | AP |
|---|---|---|
| 一致性 | 强一致 | 最终一致 |
| 可用性 | 分区时不可用 | 始终可用 |
| 响应时间 | 可能较长（等待同步） | 快速响应 |
| 适用场景 | 金融、支付（数据必须准确） | 电商、社交（允许短暂不一致） |
1.6 实际案例分析
案例一：Zookeeper（CP）
选举 Leader 期间（网络分区）：
- Leader 在分区 A → 分区 A 正常服务
- 分区 B 无法选举 Leader → 拒绝服务
- 保证一致性，牺牲可用性案例二：Eureka（AP）
网络分区期间：
- 各节点独立工作，互相注册
- 可能返回旧数据（其他节点的新注册信息）
- 保证可用性，牺牲一致性二、BASE 理论
2.1 什么是 BASE？
BASE 是 CAP 中 AP 的延伸，是对最终一致性的描述：
| 特性 | 英文 | 含义 |
|---|---|---|
| BA | Basically Available | 基本可用 |
| S | Soft State | 软状态 |
| E | Eventually Consistent | 最终一致性 |
2.2 基本可用（Basically Available）
含义：系统出现故障时，允许损失部分可用性。
表现：
- 响应时间延长（正常 100ms → 异常 500ms）
- 降级服务（返回默认值或缓存数据）
java
// 降级示例
try {
result = getUserFromRemoteService(userId);
} catch (Exception e) {
// 服务不可用，返回缓存数据
result = getUserFromCache(userId);
}2.3 软状态（Soft State）
含义：允许系统中的数据存在中间状态，且不影响系统整体可用性。
表现：
-
数据同步有延迟
-
存在中间状态
订单支付状态：
UNPAID → PAYING → PAID
↑
软状态（中间状态）
2.4 最终一致性（Eventually Consistent）
含义：系统保证最终数据一致，但不保证实时一致。
与强一致对比：
| 类型 | 含义 | 场景 |
|---|---|---|
| 强一致 | 写入后立即一致 | 金融转账 |
| 弱一致 | 一段时间后可能一致 | 缓存更新 |
| 最终一致 | 保证最终会一致 | 电商订单、社交动态 |
2.5 最终一致性的实现方式
| 方式 | 说明 | 示例 |
|---|---|---|
| 读时修复 | 读取时检查并修复数据 | DynamoDB |
| 写时修复 | 写入时同步修复相关数据 | Cassandra |
| 异步补偿 | 定时任务或消息队列补偿 | 电商订单同步 |
| 版本向量 | 用版本号判断数据新旧 | Cassandra |
三、CAP 与 BASE 的关系
3.1 核心思想
- CAP：分布式系统最多满足两个特性（P 必须保证）
- BASE：是对 CAP 中 AP 方案的延伸，接受最终一致性
3.2 如何选择？
需要强一致（如金融） → CP 系统（Zookeeper）
可以接受最终一致（如电商） → AP 系统（Eureka） + BASE 理论3.3 实际案例
电商订单场景：
用户下单：
1. 订单系统创建订单（主库）
2. 发送 MQ 消息
3. 库存系统异步扣减库存
4. 积分系统异步增加积分
设计选择：
- 主流程：订单创建必须强一致（CP）
- 异步流程：库存、积分最终一致即可（AP + BASE）四、一致性模型对比
4.1 强一致性
含义：写入后立即对所有读请求可见。
实现：
- 同步复制（所有节点写入成功才返回）
- Paxos / Raft 算法
适用：金融、支付
4.2 弱一致性
含义：写入后不保证立即一致，可能读取到旧数据。
实现：
- 异步复制
- 缓存更新延迟
适用：缓存系统
4.3 最终一致性
含义：弱一致性的特例，保证最终会一致。
实现：
- 消息队列异步补偿
- 定时任务对账
适用：电商、社交
🗺️ 思维导图速览
分布式理论基础
├── CAP 定理
│ ├── C：一致性（所有节点数据一致）
│ ├── A：可用性（每个请求都能得到响应）
│ ├── P：分区容错性（网络分区时仍能运行）
│ ├── P 必须保证 → 只能选 C 或 A
│ ├── CP：Zookeeper（强一致，分区时拒绝服务）
│ └── AP：Eureka（最终一致，始终可用）
├── BASE 理论（AP 的延伸）
│ ├── 基本可用（允许损失部分可用性）
│ ├── 软状态（允许中间状态）
│ └── 最终一致性（保证最终会一致）
└── 一致性模型
├── 强一致（写入后立即一致）
├── 弱一致（可能读取旧数据）
└── 最终一致（保证最终一致）📝 写在最后
学习建议
- CAP 要记住三选二：P 必须保证，只能在 C 和 A 之间选择
- CP vs AP 要知道代表系统：CP 是 Zookeeper，AP 是 Eureka
- BASE 是 AP 的延伸：基本可用、软状态、最终一致性
- 实际场景要知道怎么选择：金融用 CP，电商用 AP + BASE
面试回答模板
Q：说说 CAP 定理？
CAP 是分布式系统三个特性：一致性（C）、可用性（A）、分区容错性（P）。由于网络分区是必然存在的，P 必须保证，所以只能在 C 和 A 之间选择。CP 系统保证一致性，网络分区时拒绝服务，如 Zookeeper；AP 系统保证可用性，允许返回旧数据，如 Eureka。
Q：什么是 BASE 理论？
BASE 是对 CAP 中 AP 方案的延伸，包含基本可用（允许损失部分可用性）、软状态（允许数据存在中间状态）、最终一致性（保证数据最终会一致）。比如电商订单系统，主流程强一致，库存和积分通过 MQ 异步处理，最终一致即可。
Q：CAP 和 BASE 的关系？
CAP 是分布式系统的理论基础，说明最多满足两个特性（P 必须保证）；BASE 是对 CAP 中 AP 方案的延伸，接受最终一致性。实际应用中，金融系统选择 CP 保证强一致，电商系统选择 AP + BASE 接受最终一致。