CAP定理（又称布鲁尔定理）指出：在分布式系统中，**一致性（Consistency）、可用性（Availability）、分区容错性（Partition Tolerance）**
CAP定理（又称布鲁尔定理）指出：在分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition Tolerance）这三个特性无法同时满足全部三个，最多只能同时满足其中两个。
- C（一致性）：所有节点在同一时刻看到的数据是完全一致的（线性一致性或强一致性），即每次读操作都能获得最新写入的结果。
- A（可用性）：每个请求（无论成功或失败）都必须在有限时间内返回响应（不保证数据最新，但系统永不拒绝服务）。
- P（分区容错性）：系统在网络分区（如节点间通信中断）发生时，仍能继续运行。现代分布式系统通常必须满足P（因网络不可靠是常态），因此实际权衡常在CP（如ZooKeeper、etcd）和AP（如Cassandra、DynamoDB）之间选择。
⚠️ 注意：CAP 是对系统在分区发生时的行为约束的理论概括，不是设计时的静态配置；它描述的是最坏情况下的取舍，而非日常性能指标。此外，“一致性”在CAP中特指强一致性（linearizability），不同于ACID中的C或最终一致性等其他一致性模型。
# 示例：CP系统（etcd）在分区时可能拒绝部分请求以保C+P# AP系统（Cassandra）在分区时仍接受读写，但可能返回旧值（牺牲C保A+P）CAP中的“一致性”（Consistency）与ACID中的“一致性”（Consistency）名称相同，但内涵完全不同，属于不同层面、不同语境下的概念，极易混淆——这是分布式系统学习中的关键辨析点。
✅CAP中的C（Consistency）
- 指线性一致性（Linearizability），即强一致性的一种严格形式；
- 要求：所有节点对数据的读操作，总是能立即看到最新成功写入的值，且操作看起来像按某个全局时间顺序串行执行；
- 是分布式系统在并发与网络延迟/分区场景下对读写行为的实时性约束；
- 本质是关于复制数据的可见性与时序保证，不涉及业务规则。
✅ACID中的C（Consistency）
- 指数据库状态始终满足预定义的完整性约束和业务规则（如外键约束、唯一性、检查条件、事务内不变量等）；
- 例如：转账前后总金额不变（这其实是原子性+业务逻辑共同保障的语义一致性，ACID本身不直接保证该业务规则，而是提供机制让应用可实现它）；
- 是单节点（或强同步多副本）数据库在事务执行前后对数据语义正确性的保证；
- 本质是关于数据合法性和业务逻辑正确性，与分布式复制无关。
📌 关键区别总结：
| 维度 | CAP中的C | ACID中的C |
|---|---|---|
| 层级 | 分布式系统层（跨节点） | 数据库事务层（单库或强一致集群内） |
| 保障目标 | 读操作看到最新写（时序可见性） | 数据满足约束/不变量（语义合法性） |
| 是否依赖网络 | 是（直面分区与延迟） | 否（假设底层存储可靠、无分区） |
| 可否被牺牲 | 是（AP系统主动放弃） | 不应被牺牲（违反即数据错误） |
| 典型反例 | 读到过期副本数据 | 插入重复主键、余额为负、外键不存在 |
⚠️ 补充说明：
- 一个系统可以同时满足ACID的C（如PostgreSQL单实例）和CAP的CP（如etcd），但二者解决的问题正交；
- 在分布式数据库中（如Spanner、CockroachDB），需同时兼顾ACID-C（语义正确）和CAP-C（线性一致读），这需要复杂机制（如TrueTime、共识协议+事务调度）。