1.1 从单机到分布式#

随着互联网规模的爆发式增长，单机系统无法满足海量数据存储和高并发访问的需求。分布式系统成为必然选择：

分布式系统带来了新问题：网络不可靠。节点之间的通信可能延迟、丢失、中断。如何在网络故障时保证系统的正确运行，成为分布式系统设计的核心挑战。

1.2 Eric Brewer 的预言#

2000 年，加州大学伯克利分校的 Eric Brewer 在 ACM Symposium on Principles of Distributed Computing（PODC）上提出了 CAP 猜想：

2002 年，Seth Gilbert 和 Nancy Lynch 在 ACM SIGACT News 上发表了题为 “Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services” 的论文，正式证明了 CAP 定理。

1.3 CAP 定理的形式化陈述#

CAP 定理：在一个分布式系统中，当发生网络分区时，系统无法同时满足一致性和可用性。

2.1 什么是 CAP 中的一致性？#

CAP 定理中的一致性指强一致性（Strong Consistency），也称为线性一致性（Linearizability）：

任何时刻，所有节点看到的数据都是相同的。对于客户端而言，读操作总是返回最近一次写操作的结果。

2.2 强一致性的代价#

实现强一致性需要同步复制：

1
# 强一致性的写入流程
2
def write_strong(key, value):
3
    # 1. 写入主节点
4
    primary.write(key, value)
5

6
    # 2. 同步复制到所有副本
7
    for replica in replicas:
8
        success = replica.sync_write(key, value)
9
        if not success:
10
            # 任意副本失败，整体失败
11
            return False
12

13
    # 3. 返回成功
14
    return True

代价：

2.3 一致性的实现机制#

3.1 什么是可用性？#

CAP 定理中的可用性定义为：

系统收到的每个请求，都会在合理时间内返回非错误的响应（不保证返回的是最新数据）。

3.2 可用性的量化指标#

通常用 “几个 9” 来描述可用性：

3.3 高可用的设计原则#

4.1 什么是网络分区？#

网络分区是指分布式系统中，节点之间的网络通信中断，导致系统被分割成多个无法通信的子集：

4.2 分区容错的含义#

分区容错性是指：

当网络分区发生时，系统仍然能够继续运行（根据选择 C 或 A，以不同方式运行）。

关键认知：在分布式系统中，网络分区不是”会不会发生”的问题，而是”什么时候发生”的问题。

1
# 网络分区的常见原因
2
partition_causes = [
3
    "网络设备故障（路由器、交换机）",
4
    "光纤被挖断",
5
    "机房断电",
6
    "网络拥塞导致超时",
7
    "配置错误",
8
    "软件 Bug",
9
]

4.3 为什么分区容错不可妥协？#

在分布式系统中，分区容错是必须的：

原因：

1. 网络本质不可靠：TCP/IP 协议本身不保证可靠传输
2. 规模越大，故障越频繁：Google 每天处理数千次网络故障
3. 软件复杂度：配置错误、Bug 导致的分区
4. 物理因素：施工挖断光缆、机房事故

5.1 CAP 的本质矛盾#

当网络分区发生时，系统面临两难选择：

5.2 形式化证明#

假设存在一个系统同时满足 C、A、P：

证明过程：

1. 系统发生网络分区，节点 A 和节点 B 无法通信
2. 客户端写入 x = 1 到节点 A
3. 客户端从节点 B 读取 x
4. 如果节点 B 响应，返回什么？
   • 返回 0：违背一致性（应该是 1）
   • 返回 1：节点 B 如何知道？（无法从 A 同步）
   • 不响应：违背可用性

结论：三者不可能同时满足。

5.3 选择矩阵#

6.1 CP 系统的特点#

选择 CP 的系统在网络分区时，为了保证一致性，会拒绝部分请求：

6.2 ZooKeeper：典型的 CP 系统#

ZooKeeper 使用 ZAB 协议（ZooKeeper Atomic Broadcast）实现一致性：

ZooKeeper 的 CP 特性：

6.3 HBase 的 CP 设计#

HBase 依赖 HDFS 和 ZooKeeper 实现一致性：

6.4 CP 系统的适用场景#

7.1 AP 系统的特点#

选择 AP 的系统在网络分区时，优先保证可用性，允许返回旧数据：

7.2 Cassandra：典型的 AP 系统#

Cassandra 使用 无主架构（Leaderless）实现高可用：

Quorum 机制：

1
# Cassandra 的 Quorum 计算
2
N = 5  # 复制因子
3
W = 3  # 写入确认数
4
R = 3  # 读取确认数
5

6
# W + R > N 保证读到最新写入
7
if W + R > N:
8
    print("保证一致性")  # 3 + 3 > 5
9

10
# 调整 W 和 R 权衡一致性和可用性
11
# W = 1, R = 1: 高可用，可能读到旧数据
12
# W = ALL, R = 1: 强一致，可用性低

7.3 DynamoDB 的 AP 设计#

Amazon DynamoDB 采用类似的设计哲学：

读取一致性配置：

7.4 AP 系统的适用场景#

8.1 传统数据库的 CA 假设#

传统 RDBMS（如单机 MySQL、PostgreSQL）假设网络不会分区：

8.2 分布式扩展后的困境#

当传统数据库尝试分布式扩展时，面临两难：

8.3 分布式数据库的选择#

9.1 “三选二”的误导#

CAP 定理常被误解为”在设计时选择两项保留”，但实际上：

Brewer 2012 年的澄清：

“三选二”的表述具有误导性。实际上，分区很少发生，系统在正常情况下可以同时满足 C 和 A。CAP 的选择只在分区发生时才需要做出。

9.2 一致性不是二元的#

CAP 中的 C 指的是线性一致性，但实际上存在多种一致性级别：

9.3 可用性也有程度之分#

CAP 中的 A 是”完全可用”，但实际系统有不同程度的可用性：

1
# 可用性的度量维度
2
availability_aspects = {
3
    "响应时间": "99% 请求在 100ms 内响应",
4
    "成功率": "99.9% 请求成功",
5
    "覆盖范围": "分区时部分功能可用",
6
    "降级策略": "读可用但写不可用",
7
}

9.4 PACELC 作为扩展#

PACELC 是对 CAP 的扩展：

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

10.1 BASE 的定义#

BASE 是对 CAP 中 AP 系统的补充设计哲学：

• Basically Available：基本可用
• Soft state：软状态
• Eventually consistent：最终一致性

10.2 最终一致性的实现#

10.3 最终一致性的时间窗口#

1
# 最终一致性的不确定性窗口
2
def eventual_consistency_window():
3
    """
4
    从写入成功到所有副本同步的时间窗口
5
    """
6
    write_time = 0  # 写入成功时刻
7
    replication_lag = random(10, 1000)  # 复制延迟，毫秒
8

9
    # 在这个窗口内，不同客户端可能读到不同值
10
    inconsistency_window = (write_time, write_time + replication_lag)
11

12
    return inconsistency_window

影响窗口大小的因素：

10.4 解决最终一致性的方案#

11.1 决策框架#

选择 CP 还是 AP，需要根据业务场景决定：

11.2 按场景选择#

11.3 混合策略#

实际系统往往不是纯粹的 CP 或 AP，而是混合策略：

11.4 可配置的一致性#

现代系统允许动态调整一致性级别：

1
// Cassandra 一致性级别配置
2
// 写入
3
consistency_level = ConsistencyLevel.QUORUM;  // 写入多数节点
4

5
// 读取
6
consistency_level = ConsistencyLevel.ONE;     // 读取一个节点，快速但可能旧
7
consistency_level = ConsistencyLevel.QUORUM;  // 读取多数节点，保证最新
8
consistency_level = ConsistencyLevel.ALL;     // 读取所有节点，最强一致

1
# DynamoDB 读取配置
2
# 最终一致读取
3
response = table.get_item(
4
    Key={'id': '123'},
5
    ConsistentRead=False  # 默认，快但可能旧
6
)
7

8
# 强一致读取
9
response = table.get_item(
10
    Key={'id': '123'},
11
    ConsistentRead=True   # 慢但保证最新
12
)

12.1 CAP 定理的核心要点#

12.2 设计决策清单#

设计分布式系统时，回答以下问题：

12.3 实践建议#

1. 分区是常态：设计时假设网络分区会发生
2. 分级一致性：不同数据采用不同一致性级别
3. 监控复制延迟：了解最终一致性的窗口
4. 降级策略：分区时有预案，而非崩溃
5. 客户端补偿：读自己写、版本向量等技术

12.4 经典案例对比#

CAP 定理告诉我们，分布式系统设计没有银弹。理解业务需求，在一致性、可用性、延迟之间做出明智的权衡，才是优秀架构师的核心能力。