从 CAP 到 PACELC：分布式系统一致性模型的工程博弈

分布式系统的设计从未有过"银弹"，只有永恒的权衡。当我们谈论一致性模型时，往往陷入理论的深潭，而忽略了工程实践中那些更微妙、更棘手的取舍。本文将从 CAP 定理出发，深入剖析 PACELC 的演进逻辑，并结合邮件系统的实际场景，探讨如何在一致性、可用性和延迟之间找到最佳平衡点。

一、CAP 定理：不完美的三角

Brewer 在 2000 年提出的 CAP 定理指出：在一个分布式系统中，Consistency（一致性）、Availability（可用性）、Partition tolerance（分区容错性）三者不可兼得，最多只能同时满足其中两个。

但这里的表述常常被误解。CAP 并非说你必须三选二，而是说当网络分区发生时，你必须在一致性和可用性之间做出选择。在网络正常时，三者是可以同时保障的。

三个属性的工程含义：

• 强一致性 (Strong Consistency)：写入成功后，所有后续读取都能看到最新值。代价是协调延迟和可用性损失。
• 高可用性 (High Availability)：每个请求都能收到非错误响应，但不保证是最新的数据。
• 分区容错 (Partition Tolerance)：系统在网络分区时仍能继续工作。在实践中是必选项，因为你无法保证网络永远畅通。

以邮件系统为例：当你从两台不同的设备查看收件箱时，你期望看到相同的邮件列表——这就是一致性需求。但当网络不稳定时，你仍然希望能够查看缓存的邮件——这就是可用性需求。

二、PACELC：更完整的权衡框架

PACELC 定理 (Abadi, 2012) 是对 CAP 的重要扩展。它指出：

• 如果有 Partition (P)，必须在 Availability (A) 和 Consistency (C) 之间选择
• 否则 (Else, E)，必须在 Latency (L) 和 Consistency (C) 之间选择

这个"Else"分支恰恰是工程实践中最常遇到的情况。没有网络分区时，你依然面临抉择：是等待数据同步完成以确保一致性（增加延迟），还是直接读取本地数据（降低延迟但可能读到旧数据）？

PACELC 将系统分为四类：

PC/EC 类型的代表是 Google Spanner，它通过 TrueTime API 和原子钟/GPS 时钟的混合使用，将分布式事务的提交延迟控制在毫秒级，同时保证强一致性。这证明了"选择一致性"并不必然意味着高延迟，但需要巨大的基础设施投入。

三、一致性光谱：从线性到最终

一致性并非非黑即白，而是一个连续的光谱。理解这个光谱是工程决策的基础。

3.1 线性一致性 (Linearizability)

线性一致性是最强的一致性保证。它要求：

1. 每个操作都在其调用和响应之间的某个时间点原子性地完成
2. 所有操作的执行顺序与全局时钟一致

在 Rust 中，我们用 Mutex 可以实现单机的线性一致性语义：

use std::sync::{Arc, Mutex};

struct LinearizableStore {
    data: Mutex