CAP 和 BASE 是什么？为什么不能简单理解成“三选二”？

知识点详解：两边暂时联系不上，系统还能答应什么

先用一份共享配置观察分区

假设两个机房共享某个配置值。A 机房完成修改，随后 B 收到读取请求，但它联系不到 A，也没有收到新值。

B 若直接返回旧值，可以继续服务，却不满足这里要求的最新读写顺序；若要守住这个顺序，就不能无条件完成这次读取。

这是针对共享数据和故障模型的判断。返回一个错误页面不等于完成了读写数据对象的可用性保证。

CAP 的词，和日常术语不完全一样

C 在相关定理中是线性一致性：操作看起来有一个符合实际先后关系的统一顺序。它和 ACID 中维护数据库规则的“一致性”不能直接划等号。

A 是模型里的请求完成保证，不是监控上的 99.9% SLA。P 则是面对节点间消息无法正常传递的情况，不是你可以靠愿望关掉的开关。

没有分区时也要考虑延迟与协调成本，但不能把所有性能权衡都叫 CAP 证明。

BASE 不表示业务规则可以先不管

假设文章浏览量允许稍后汇总，可以先各自累计，再通过定义好的机制合并。这个方向可以接受暂时不同的显示结果。

但如果某个权限已被撤销，是否还允许旧副本授权，就需要另外判断。不同数据不必采用相同容忍度。

最终一致要有条件：更新停止后，传播和冲突处理能让副本收敛。消息永远丢失、冲突没有规则，等待多久都不会自动变正确。

把取舍写成分区与恢复两份约定

分区期间，哪些读取可用旧值、哪些写入必须拒绝、是否能先记录待处理意图，都要明确。界面不能把“已受理”显示成“已经生效”。

恢复之后，要补发遗漏更新、去重、处理冲突，并检查不变量。需要人工处理的差异也应有入口，不能只让日志不断报错。

面试选型可以从一个具体操作回答，再扩展到模块，不必追求整个产品只有一种标签。

本题机制参考：Gilbert 与 Lynch CAP 论文、Brewer 十二年回顾。

面试官继续追问

CP 就意味着系统一直不可用吗？

不是，讨论的是相关故障下部分操作的保证；正常状态仍可以提供服务。

最终一致有没有规定几秒？

术语本身没有统一秒数。产品若承诺收敛时限，需要额外机制和测试。

ACID 和 BASE 必须全系统二选一吗？

不是。局部数据库事务和跨模块异步收敛可以共存，边界需要说明。

面试速记卡

• CAP：分区下的保证冲突，不是随时三选二。
• C：线性一致性；不要直接等同 ACID 的 C。
• A：请求完成保证；不要等同 SLA 百分比。
• BASE：设计取向，不自动修复冲突。
• 工程：逐操作定义分区行为和恢复规则。