一致性与 CAP

分布式数据库 无法同时 保证分区容忍（P）下的强一致（C）与永远可用（A）——CAP 是 Specialty 选型与 scaling-essentials 的共同语言。本课把各库的默认取舍 映射到 CAP，避免口号式「最终一致」。

学习目标

C（Consistency）  所有节点同一时刻看到相同数据
A（Availability） 每个请求都能得到非错误响应
P（Partition tolerance） 网络分区时系统仍能继续工作

分布式系统 P 必选 → 分区发生时只能在 C 与 A 之间权衡

不是三选二弃一：正常运行时可兼顾；分区发生时 才显式降级。

系统	分区时倾向	可调机制
PostgreSQL 单主	CP（主不可达则写失败）	同步复制提高 C
Cassandra	AP 默认	QUORUM 提高读一致
MongoDB	可配 CP/AP	writeConcern / readConcern
DynamoDB	最终一致读 vs 强一致读	ConsistentRead 参数
Elasticsearch	AP 搜索	refresh、wait_for_active_shards
Neo4j 集群	偏 CP	因果集群模式

与 ddb-crud 的条件写、mongo-crud 的 concern 参数 同一逻辑不同 API。

若无分区（Else）→ 在 Latency 与 Consistency 间权衡

例如：DynamoDB 强一致读更慢；Cassandra LOCAL_QUORUM 降延迟 但缩小一致范围。扩展决策见 scale-intro。