CAP 定理

是什么，为什么存在

CAP 定理描述带复制的共享数据系统在网络通信中断时受到的限制。这里的三个字母分别表示一致性（consistency）、可用性（availability）和分区容错性（partition tolerance）。它不是数据库选型打分表，而是一条不可能性结论：在允许消息丢失的模型里，不存在同时满足三项保证的算法。

CAP 中的一致性通常指线性一致性（linearizability）。每个已完成的操作看起来都在调用与返回之间的某一瞬间原子发生，而且这个顺序尊重真实时间。一次写入返回成功后，随后开始的读取不能合法地返回更旧的值；这比“副本最后会相同”强得多。

CAP 中的可用性也有特定含义。非故障节点收到的每个请求最终都要完成，并给出符合对象规格的响应。为了保护一致性而拒绝本来有效的读写，或者无限等待失联副本，都表示该操作没有获得 CAP 所说的可用性；这与季度可用率或延迟 SLO 不是同一个指标。

网络分区（network partition）意味着节点之间的一部分消息可能丢失或无限延迟，而分区两侧的节点本身仍在运行。节点只能看到本地消息，无法可靠区分对端宕机、链路断开和极慢的网络。在跨节点保存同一份可变状态时，这种信息缺失迫使系统做出选择。

你会在多区域数据库、服务发现、配置存储、购物车和离线客户端中遇到这个限制。CAP 最有用的地方不是给整套产品贴上 CP 或 AP 标签，而是追问某个操作在超时后还能承诺什么。

工作原理

设两个副本起初都保存 v1，随后它们之间的链路断开。左侧收到把值改为 v2 的请求，但无法知道右侧是否仍对外服务。如果左侧确认写入，右侧稍后的读取可能仍返回 v1，真实时间顺序便无法保持线性一致。

若要保留一致性，系统必须阻止至少一侧完成会产生冲突的操作。它可以让拥有有效多数派的一侧继续，把少数派变为只读，也可以在无法确认提交时返回失败。代价是某些健康节点仍在运行，请求却不能成功完成。

若要保留可用性，两侧都必须在收不到对方消息时继续响应。这样可以接受本地写入并返回本地读取，但副本可能分叉。通信恢复后，系统还需要检测并发更新、确定合并规则，并处理已经对用户或外部系统产生的效果。

图中的两个结果不是永久的产品类型。系统可以让余额扣减走一致路径，让商品目录读取走可用路径；同一操作在不同故障阶段也可以改变策略。Eric Brewer 后来特别强调，应显式检测分区、进入分区模式，再执行恢复，而不是把 CAP 简化成静态的“三选二”。

形式证明讨论的是模型中的保证，工程系统还必须把“多久没有消息算作分区”落到超时上。超时太短会把拥塞误判为分区，过早降级；超时太长则会把用户请求悬挂在一致路径上。CAP 不会替你选这个时间，也不会给出恢复协议。

设计评审至少要写清四件事：一致性的对象与范围、哪些请求必须完成、故障模型包含哪些消息丢失，以及分区恢复后如何处理状态和外部副作用。缺少其中任何一项，“我们选择 CP”都不是可测试的需求。

示例

下面的程序都是教学模型，不是分布式存储实现。它们把关键决策缩到单个进程中，因此可以稳定重放；真实系统还需要成员关系、持久化、重试、共识和故障注入测试。

同一次分区中的两条路径

第一个模型从两个值相同的副本开始。cpWrite 在链路断开时拒绝写入，所以旧状态没有分叉；apWrite 接受本地写入，所以两个健康副本随即能返回不同值。

这段代码没有证明拒绝写入就自动获得线性一致性。真实的 CP 路径必须确认自己有权提交，例如持有当前任期内的多数派；一个被隔离的旧主节点不能只根据本地布尔值继续写。示例只展示分区发生后最小的不可兼得关系。

AP 路径同样没有免费解决冲突。v2 已经向左侧调用者公开，右侧仍可能接受另一个值。恢复逻辑不能假装其中一次操作从未发生，除非业务规格明确允许丢弃它并处理已外显的后果。

按操作定义分区策略

CAP 的选择应落到操作与不变量，而不是落到整套服务。浏览目录可以容忍旧快照，收藏集合可以采用可合并的操作，最后一个座位的预订则需要知道全局当前状态。

function partitionPolicy(operation) {
  if (operation.needsCurrentGlobalState) {
    return 'reject and retry after recovery';
  }
  if (operation.mergeable) {
    return 'accept locally and merge later';
  }
  return 'serve local snapshot';
}

const operations = [
  {
    name: 'view catalog',
    needsCurrentGlobalState: false,
    mergeable: false,
  },
  {
    name: 'add favorite',
    needsCurrentGlobalState: false,
    mergeable: true,
  },
  {
    name: 'reserve last seat',
    needsCurrentGlobalState: true,
    mergeable: false,
  },
];

for (const operation of operations) {
  console.log(`${operation.name}: ${partitionPolicy(operation)}`);
}

view catalog: serve local snapshot
add favorite: accept locally and merge later
reserve last seat: reject and retry after recovery

策略表首先区分读取、可合并写入和受全局不变量约束的写入。最后一项被延迟，是因为两个分区各自出售“最后一个座位”会把一个不可撤销承诺外显给用户。另一种设计可以预先把座位或额度分配给各区域，但那是改变不变量的所有权，不是绕过 CAP。

代码里的 mergeable 也必须由真实的代数性质支撑。操作应具有确定的合并结果，并对重复投递安全；只在字段上写一个布尔标记不会让任意更新自动收敛。

多数派为什么要相交

多数派法定人数（quorum）的基本价值是任意两个多数派都至少共享一个副本。五个副本取三个时，最小交集为一；四个副本只取两个时，可以出现完全不相交的两组。

function combinations(values, size) {
  if (size === 0) return [[]];
  return values.flatMap((value, index) =>
    combinations(values.slice(index + 1), size - 1).map((rest) => [value, ...rest]),
  );
}

function minimumOverlap(replicaCount, quorumSize) {
  const nodes = Array.from({ length: replicaCount }, (_, index) => index);
  const quorums = combinations(nodes, quorumSize);
  let result = { size: replicaCount, witness: null };

  for (const [index, left] of quorums.entries()) {
    for (const right of quorums.slice(index + 1)) {
      const size = left.filter((node) => right.includes(node)).length;
      if (size < result.size) result = { size, witness: [left, right] };
    }
  }
  return result;
}

for (const [replicas, quorum] of [[5, 3], [4, 2]]) {
  const { size, witness } = minimumOverlap(replicas, quorum);
  console.log(`N=${replicas}, Q=${quorum}, minimum overlap=${size}`);
  if (size === 0) console.log('disjoint witness:', JSON.stringify(witness));
}

N=5, Q=3, minimum overlap=1
N=4, Q=2, minimum overlap=0
disjoint witness: [[0,1],[2,3]]

交集可以防止两个不相交分区都凑出多数派，但它只是必要结构。线性一致的存储还要让交集节点遵守任期、日志或版本规则，正确处理并发写入和成员变更。把 W + R > N 写进配置，并不能单独证明整个协议正确。

对于五副本系统，失去三个副本后，剩下两个节点仍然健康，却无法形成三节点多数派。一致路径因此停止完成操作，这正是分区期间放弃可用性的具体表现。读路径能否继续，还取决于所承诺的读取语义，而不是“读总是安全”。

可合并状态如何恢复

如果业务操作能表示为可交换、幂等的状态更新，分区两侧可以继续并在恢复后收敛。下面的增长计数器为每个节点保存单调递增的分量；合并时逐项取最大值，重复合并不会重复计数。

class GCounter {
  constructor(node, counts = {}) {
    this.node = node;
    this.counts = { ...counts };
  }

  increment() {
    this.counts[this.node] = (this.counts[this.node] ?? 0) + 1;
  }

  merge(other) {
    const nodes = new Set([...Object.keys(this.counts), ...Object.keys(other.counts)]);
    const merged = Object.fromEntries(
      [...nodes].map((node) => [
        node,
        Math.max(this.counts[node] ?? 0, other.counts[node] ?? 0),
      ]),
    );
    return new GCounter(this.node, merged);
  }

  get value() {
    return Object.values(this.counts).reduce((total, count) => total + count, 0);
  }
}

let paris = new GCounter('paris');
let tokyo = new GCounter('tokyo');

for (let count = 0; count < 2; count += 1) paris.increment();
for (let count = 0; count < 3; count += 1) tokyo.increment();

console.log('during partition:', paris.value, tokyo.value);
paris = paris.merge(tokyo);
tokyo = tokyo.merge(paris);
console.log('after merge:', paris.value, tokyo.value);
console.log('merge again:', paris.merge(tokyo).value);

during partition: 2 3
after merge: 5 5
merge again: 5

分区期间两个副本分别看到 2 和 3，所以读取并不线性一致。交换状态后，两边都得到 5；再次合并仍为 5，说明该合并是幂等的。这个例子展示的是最终一致性（eventual consistency）的一种实现方式，不是 CAP 的通用解法。

增长计数器只能增加，不能直接撤销一次计数。支持删除、唯一性、余额下限或跨对象事务需要更丰富的状态和协议。有些全局不变量无法仅靠局部合并保持，此时必须分配权限、协调，或者在分区期间拒绝相关操作。

恢复还包括状态之外的外部效果。两个副本最终得到同一个数字，并不会自动撤回重复发送的邮件、重复扣款或冲突的座位确认。外部命令需要幂等键、去重记录或明确的补偿流程。

陷阱

只有允许分区并要求两侧继续处理同一份状态时，不可能性才迫使一致性与可用性发生冲突。网络正常时，系统可以同时提供线性一致的结果并完成请求；同一系统也可以对不同操作采用不同策略。

修复方法： 按操作记录分区模式，而不是只写产品标签。为每个操作说明正常路径、超时路径、恢复路径和必须保持的不变量。

ACID 中的一致性是事务把数据库从一个满足约束的状态带到另一个满足约束的状态。CAP 的一致性讨论操作历史能否线性化；最终一致性只承诺停止更新后副本会收敛。三者回答的问题不同，一个系统可能同时拥有其中若干项。

修复方法： 在需求和接口中写出具体模型，例如 linearizable per key、read-your-writes within a session 或 eventual convergence。不要只写“强一致”。

同一产品可能提供线性一致读取、陈旧读取、不同写确认级别和异步跨区域复制。控制面与数据面也可能作出不同选择。一个无范围说明的标签无法预测具体请求在故障时的行为。

修复方法： 验证正在使用的版本与配置，并用操作历史描述保证。测试客户端实际调用的 API，而不是引用一张静态分类表。

客户端没有收到响应，只能说明结果未知；提交确认可能在返回途中丢失。若重试的是扣款、发货或创建资源，系统可能把一次意图执行两次。这个问题在生成的故障转移代码里很常见。

修复方法： 为非幂等命令使用稳定的幂等键，并提供按键查询最终结果的接口。协议应区分明确失败、明确成功和结果未知三种状态。

法定人数相交不等于协议正确；时钟也可能偏移，让较晚的时间戳覆盖真实时间中更晚的业务操作。成员变更、部分写入和并发写入仍需要明确规则。最后写入胜出还会有意丢弃一个值。

修复方法： 说明版本顺序来自任期、日志索引、混合逻辑时钟还是其他机制，并测试时钟回拨与成员变化。若业务不能接受丢失更新，就不要把最后写入胜出作为默认合并策略。

AI 时代

智能体可以把拟议的副本写入路径变成可运行的故障实验。假设契约规定同一任期内只能由一个主节点接受对同一键的写入，智能体可以在旧主节点与成员变更重叠时注入单向丢包，记录产生的操作历史，并把两个主节点都接受这类写入的轨迹缩减为最小反例。实验会让选择变得具体：在分区期间拒绝或延迟某类操作，在响应丢失后暴露未知结果，或者定义一种能够保留指定业务不变量的合并方式。把缩减后的操作历史保留为所选策略的回归测试。

延伸阅读

• Jepsen：一致性模型的关系与定义
• Google SRE：共识、法定人数与关键状态
• Daniel Abadi：提出 PACELC 的原始讨论
• Jepsen：线性一致性的定义与历史模型