CAP 在说什么
CAP 指出网络分区发生时，系统只能在一致性与可用性之间取舍：要保证所有节点读到相同数据，就得拒绝部分请求；要保证每个请求都有响应，就可能读到旧数据。分区在跨机房部署里难以避免，所以选型的实质是决定一致性优先还是可用性优先。
PACELC 补上了平时的情况
PACELC 把问题分成两半：发生分区时在可用性与一致性之间选，其余时间则在延迟与一致性之间选。写确认级别、读偏好、刷新间隔这些具体参数，就是抽象取舍落到配置上的旋钮。
基本信息
| C 一致性 | 所有节点读到相同数据，常见于强一致主从架构与共识协议 |
|---|---|
| A 可用性 | 每个请求都能得到响应，但不保证最新 |
| P 分区容忍 | 部分节点失联时系统仍能运转，跨机房部署的必选项 |
| PACELC | 有分区时选可用或一致，无分区时选低延迟或强一致 |
| 落地方式 | 写确认级别、读偏好、刷新间隔等具体参数 |
取舍落到配置
取舍落到配置
强一致倾向：写确认多数派 + 读确认多数派
低延迟倾向：从副本读、近实时读、多活最终一致
# 示例：写入要求多数派确认
db.orders.insertOne({ sku: "A-1" }, { writeConcern: { w: "majority" } })
# 示例：读偏好设为从副本读，接受轻微旧读
db.orders.find({}).readPref("secondaryPreferred")
# 检索层同理：刷新间隔越短，可见性越快、写入开销越高典型使用场景
- 跨机房架构评审：明确分区时宁可拒绝写还是接受旧读
- 数据库选型：按业务对一致性的要求筛选候选方案
- 参数默认值评审：写确认与读偏好往往决定真实体验
- 故障预案：分区持续期间的降级策略与恢复后的数据核对
- 沟通对齐：把理论取舍翻译成业务能理解的丢数或旧读窗口
场景与取舍倾向
| 场景 | 取舍倾向 | 常见做法 |
|---|---|---|
| 支付与账务 | 一致性优先 | 多数派写确认，读主节点 |
| 内容与搜索 | 可用性优先 | 近实时读，最终一致 |
| 会话与缓存 | 可用性优先 | 允许短暂旧值，靠过期时间收敛 |
| 跨机房同步 | 按业务分层 | 关键数据强一致，其余异步 |
把抽象理论落到配置上才有意义：先明确业务能接受多大延迟与多长的旧读窗口，再决定写确认与读偏好参数，而不是照抄默认值。
把 CAP 当成"三选二"、认为可以主动放弃分区容忍，会让跨机房设计失去前提；分区不是可选设计项，而是必须应对的常态。