CAP 是什么
CAP 讨论的是网络分区发生时分布式系统的取舍：当节点间消息可能丢失或延迟任意长时间，系统只能在一致性 C（线性一致性语义）与可用性 A 之间选择放弃哪一个。无分区时两者可以同时满足，所以“三选二”是简化说法。实际系统中分区不是是否发生的问题，而是发生频率与持续时间的问题，因此 CAP 更像设计阶段的姿态选择，而不是一次性的选项勾选。
基本信息
| C 一致性 | 线性一致性：所有节点读到相同的、最新的已提交值 |
|---|---|
| A 可用性 | 每个到达非故障节点的请求都能在有限时间内得到非错误响应 |
| P 分区容忍 | 系统在消息丢失或延迟的情况下仍能继续运行 |
| 前提 | 只有发生网络分区时，C 与 A 才是互斥的 |
| 延伸 | PACELC 进一步描述无分区时延迟与一致性的权衡 |
三种姿态
| 选择 | 分区时的行为 | 代价 | 典型场景 |
|---|---|---|---|
| CP | 拒绝或阻塞部分请求以保一致 | 分区期间部分请求不可用 | 账务流水、配置与选举类组件 |
| AP | 继续服务，接受副本暂时不一致 | 需要冲突解决与事后补偿 | 购物车、社交动态、推荐 |
| CA | 仅在不分区时成立 | 真实网络下不可长期保证 | 单机数据库、同机多进程 |
典型使用场景
- 技术选型评审：判断数据库或中间件在分区时是拒写还是继续写
- 跨可用区部署设计：明确分区期间哪些接口降级、哪些必须失败
- 支付与账务链路：宁可选 CP 并暴露失败，也不接受重复扣款
- 购物车与浏览类功能：可接受 AP，用最后写入胜出或合并策略处理冲突
- 容量与超时设计：为分区后恢复期的数据补齐与对账预留资源和流程
- 对外承诺评审：把分区期间的行为写进 SLA，而不是假定永不分区
CAP 的 C 指线性一致性，与 ACID 的 C（事务前后约束不被破坏）不是同一件事；把两者混用是评审里最常见的误读。
PACELC 补充了没分区时的情况：即使网络正常，跨副本同步也要在延迟与一致性之间取舍，这通常比分区更频繁地影响用户体验。