CAP 在网络分区时限制了什么？
- C 一致性: 此处指线性一致性，操作表现得像在同一副本上按符合实时先后关系的顺序发生;
- A 可用性: 每个到达非故障节点的请求最终获得符合操作语义的响应，不是仅返回错误，也未指定有限延迟上界;
- P 分区: 节点组之间可能丢失全部消息，是需要承受的网络条件，不是随意关闭的功能;
- 不可能性: 在允许网络分区的模型中，不能同时保证所有操作都线性一致且所有非故障节点都可用;
- 直观推理: 两侧断开时，一侧已完成的新写无法被另一侧知道；另一侧只能等待或拒绝，或者返回可能过期的数据;
- 依据: Gilbert 与 Lynch 的 CAP 论文明确了模型与定义;
CP 和 AP 的业务后果如何比较？
| 选择 | 分区时的行为 | 业务代价 |
|---|
| CP | 无法安全协调的一侧限制操作 | 部分请求不可用 |
| AP | 可达节点继续按约定服务 | 可能读旧值或产生需合并的并发写 |
- CA 边界: 不考虑分区时可同时提供一致与可用，不能把跨网络数据库永久贴上“不需要容忍分区”的标签;
- 产品分类: 原文用 PostgreSQL、MariaDB、MongoDB、HBase、Cassandra、CouchDB 举例，但实际性质取决于拓扑、操作与配置;
- 原则: 按具体操作选择代价，例如库存扣减与动态列表显示可以有不同需求;
PACELC 为什么还要考虑正常状态下的延迟？
- PACELC: 若发生分区 P，在 A 与 C 之间权衡；否则 E，在低延迟 L 与一致性 C 之间考虑协调成本;
- 正常路径: 即使网络没有中断，跨区等待副本确认也要付出往返时间;
- CAP 局限: 理论上的最终响应不代表用户可接受的响应时间，因此需要另设延迟目标;
- 选择方式: 先写出允许多旧、能等多久、失败时如何降级，再决定读写确认策略;