首页/数据/NoSQL 速查/CAP 与 PACELC 基本判断
本包目录(322 条)
MongoDB99 条Elasticsearch89 条ClickHouse56 条时序与列式28 条
选型与架构50 条

CAP 与 PACELC 基本判断

CAP 指出网络分区发生时只能在一致性与可用性之间取舍;PACELC 补充正常运行时还要在延迟与一致性间取舍。分布式系统分区难以避免,选型实际是在"C 优先还是 A 优先"上做决定。

NoSQL 速查数据更新于 2026-10-12
C 一致性所有节点读到相同数据;常见于强一致主从架构与共识协议
A 可用性每个请求都能得到响应(不保证最新);常见于多主与最终一致设计
P 分区容忍部分节点失联时系统仍运转;跨机房部署必选项
PACELCPartition 时选 A 或 C,Else 时选 L(低延迟)或 C(一致性)

示例

示例
强一致倾向:MongoDB 副本集 w:majority + readConcern:majority
低延迟倾向:MongoDB 读 secondary、ES 近实时读、多地多活最终一致
取舍落到配置:写确认级别、读偏好、刷新间隔都是 CAP 的具体旋钮
把抽象理论落到配置上才有意义:先明确业务能接受多大延迟与旧读,再选写确认与读偏好参数。

易错点

  • 把 CAP 当成三选二、认为可以同时放弃 P,会让跨机房设计失去前提
  • 一致性讨论只停留在架构图:真正影响体验的是写确认与读偏好这些默认配置

数据来源与参考

  • MongoDB Manual: Read Concern
  • Elasticsearch Guide: Near real-time search
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌