CAP 定理

分布式系统无法同时完美满足 一致性（C）、可用性（A） 与 分区容忍（P）。CAP 不是口号，而是帮你在网络抖动、节点宕机时做 工程取舍 的框架。对应路线图 building-for-scale 下的分布式基础节点。

学习目标

• 用业务语言解释 C、A、P 各代表什么
• 判断常见场景（支付、Feed、配置中心）偏向 CP 还是 AP
• 避免「CAP 选一边」的简化误解，理解 PACELC 等延伸思考

核心概念

属性	含义	用户可感知表现
C 一致性	所有节点读到相同最新数据	余额、库存不会「各看各的」
A 可用性	每个请求都能得到响应（非错误/超时）	页面总能打开，哪怕稍旧
P 分区容忍	网络断连时系统仍能继续工作	跨机房链路中断时不整体瘫痪

分区（Partition）在分布式里迟早发生——因此 P 通常是前提，实际在 C 与 A 之间权衡：

• CP：强一致优先，可能拒绝写入（如 ZooKeeper 选主期间）
• AP：可用优先，允许短暂不一致（如 DNS、多副本最终一致）

网络分区发生 → 选：停写保一致（CP） vs 继续服务接受旧读（AP）

Java 后端常见映射：订单扣库存偏 CP；社交点赞计数偏 AP。复制与分片细节见 scale-replication、postgresql-essentials。

工程取舍清单

1. 这笔数据错了会不会赔钱？→ 偏 CP
2. 短暂旧数据用户能否接受？→ 可偏 AP + 补偿
3. 能否用 异步复制 + 读己之写 折中？→ 见 scale-read-write

练习

• 为你负责的三个 API 标注 CP/AP 倾向并写一句理由
• 阅读 reliability-essentials 中关于超时与重试的课，思考与 CAP 的关系
• 讨论：Redis 主从切换瞬间，算 CP 还是 AP？

小结

CAP 帮你在分区不可避免时诚实选择：要正确还是要响应——没有银弹，只有业务匹配。