5.2 一致性与可用性的权衡
CAP 是一致性与可用性权衡的理论，是理解分布式系统的起点。
1999 年，美国工程院院士 Eric A.Brewer 发表了论文《Harvest, Yield, and Scalable Tolerant Systems》[1] ，首次提出了“CAP 原理”（CAP Principle）。不过，彼时的 CAP 仅是一种猜想，尚未得到理论上的证明。2002 年，麻省理工学院的 Seth Gilbert 和 Nancy Lynch 用严谨的数学推理证明了 CAP 的正确性。此后，CAP 从原理转变成定理，在分布式系统领域产生了深远的影响。
图 5-1 CAP 定理
CAP 定理描述的是一个分布式系统中，涉及共享数据问题时，以下三个特性最多只能满足两个。
- 一致性（Consistency）：意味着数据在任何时刻、任何节点上看到的都是符合预期的。为了确保定义的严谨性，学术研究中通常将一致性定义为“强一致性”（Strong Consistency），也称为“线性一致性”（Linearizability）。
- 可用性（Availability）：可用性代表系统持续提供服务的能力。要理解可用性，首先需要了解两个密切相关的指标：可靠性（Reliability）和可维护性（Serviceability）。可靠性通过平均无故障时间（MTBF, Mean Time Between Failure）度量；可维护性通过平均修复时间（MTTR, Mean Time To Repair）度量。可用性衡量系统在总时间内可以正常使用的时间比例，计算公式为 A = MTBF / (MTBF + MTTR)。因此，可用性是通过可靠性和可维护性计算得出的比例。例如，99.9999% 的可用性意味着平均每年系统故障修复时间为 32 秒。
- 分区容错性（Partition tolerance）：当部分节点由于网络故障或通信中断而无法相互联系，形成“网络分区”时，系统仍能够继续正确地提供服务。
由于 CAP 定理已有严格的证明，我们不再探讨为何 CAP 不可兼得，直接分析舍弃 C、A、P 时所带来的不同影响。
- 放弃分区容忍性（CA without P）：意味着我们将假设节点之间通信永远可靠。永远可靠的通信在分布式系统中必定不成立，只要依赖网络共享数据，分区现象就不可避免地存在。如果没有 P（分区容错性），也就谈不上是真正的分布式系统。
- 放弃可用性（CP without A）：意味着我们将假设一旦网络发生分区，节点之间的信息同步时间可以无限制延长。在现实中，选择放弃可用性系统（又称为 CP 系统）适用于对数据一致性有严格要求的场景，如金融系统、库存管理系统等。这些应用场景中，数据的一致性和准确性通常比系统的可用性更为重要。
- 放弃一致性（AP without C）：意味着在网络分区发生时，节点之间的数据可能会出现不一致。这种情况下，系统会优先保证可用性，而不是一致性。选择放弃一致性系统（又称 AP 系统）已经成为设计分布式系统的主流选择，因为分区容错性（P）是分布式网络的固有属性，不可避免；而可用性（A）通常是建设分布式系统的目标。如果系统在节点数量增加时可用性降低，则其分布式设计的价值也会受到质疑。除了像银行和证券这样的金融交易服务，这些场景中数据一致性至关重要，通常需要保证一致性而可能接受部分中断之外，大多数系统更倾向于在节点增多时保持高可用性，而不是牺牲可用性以维持一致性。
额外知识
对于分布式系统而言，必须实现分区容错性（P）。因此，CAP 定理实际上要求在可用性（A）和一致性（C）之间选择，即在 AP 和 CP 之间权衡取舍。
从上述分析可以看出，原本事务的主要目的是保证“一致性”，但在分布式环境中，一致性往往不得不成为牺牲的属性，AP 类型的系统反而成为了分布式系统的主流。但无论如何，我们设计系统终究还是要确保操作结果至少在最终交付的时刻是正确的，这个意思是允许数据中间不一致，但应该在输出时被修正过来。
为此，工程师们又重新给一致性下了定义，将 CAP、ACID 中讨论的一致性（C）称为“强一致性”，而把牺牲了 C 的 AP 系统但又要尽可能获得正确结果的行为称为追求“弱一致性”。不过，若只是单纯地谈论“弱一致性”，通常意味着不保证一致性。在弱一致性中，工程师们进一步总结出了一种较强的特例，称为“最终一致性”（Eventual Consistency），它由 eBay 的系统架构师 Dan Pritchett 在 BASE 理论中提出。
额外知识
ACID 在英文中有的“酸”的含义，强调强一致性。BASE 在英文中有“碱”的含义，强调放弃强一致性保证可用性。酸 vs 碱衍生出 AP 型可用性架构和 CP 型强一致性架构，所以 CAP 理论又戏称度量分布式系统的“Ph试纸”。
参见 https://ieeexplore.ieee.org/document/798396 ↩︎