大家好，我是程序员柏风，AI 最全的 Vibecoding 学习地图 http://coderoadmap.cn 作者。
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。
工程取舍清单
- 这笔数据错了会不会赔钱？→ 偏 CP
- 短暂旧数据用户能否接受？→ 可偏 AP + 补偿
- 能否用 异步复制 + 读己之写 折中？→ 见 scale-read-write
练习
- 为你负责的三个 API 标注 CP/AP 倾向并写一句理由
- 阅读 reliability-essentials 中关于超时与重试的课，思考与 CAP 的关系
- 讨论：Redis 主从切换瞬间，算 CP 还是 AP？
小结
CAP 帮你在分区不可避免时诚实选择：要正确还是要响应——没有银弹，只有业务匹配。