一、CAP 是什么字母含义解释C**Consistency一致性所有节点同一时间看到的数据完全一致A**Availability可用性每个请求都能得到响应不保证数据最新P**Partition tolerance分区容错网络分区节点间通信失败时系统仍能继续工作二、为什么不能同时实现因为 P分区容错是分布式系统的前提条件**。网络分区一定可能发生断网、丢包、节点宕机。所以你必须在 C 和 A 之间二选一——这就是 CAP 的本质。2.1分布式系统必选 P为什么 P 必选分布式系统有多个节点节点间通过网络通信网络一定可能断网线被挖断、交换机故障、DNS 故障只要是分布式系统P 就必须满足2.2P 满足后C 和 A 只能二选一假设场景MySQL 主从集群主从之间网络断了主库 (192.168.1.1) ← 网络断 → 从库 (192.168.1.2) ↓ ↓ 写数据 w1 没收到情况 1选 C一致性——拒绝写主库检测到从库没收到 主库拒绝写入返回错误 主库保证数据一致主从都是空 ↓ ❌ 可用性没了用户写不进去情况 2选 A可用性——继续写主库不管从库先写入主库 主库返回写入成功 ↓ ✅ 可用性有了 ❌ 一致性没了主库有 w1从库没有**所以 P 满足后C 和 A 是互斥的——你必须牺牲一个。三、CAP 三选二的 3 种组合组合含义实际系统项目CA放弃 P单点系统不是分布式传统单机数据库MySQL 单机单库测试CP放弃 A强一致 分区容错可用性差ZooKeeper、etcd、HBase关键功能强一致AP放弃 C可用性 分区容错最终一致Eureka、Cassandra、Redis报表高可用⚠️ 关键点CA 不是真正的分布式单机就满足不分 P真实分布式只能在 CP 和 AP 之间选四、CAP 的扩展理解4.1CAP 不是三选一而是权衡老哥注意CAP 不是绝对的——不是非黑即白大部分系统在C 和 A 之间做权衡不是完全牺牲比如ZooKeeper 标榜 CP但实际写入失败后还会重试不是完全不可用4.2实际系统的 CAP 表现系统CAP实际表现EurekaAP节点挂了服务还能用不一致但可用Nacos 临时实例AP同 EurekaNacos 非临时实例CP网络断后不剔除保证一致ZooKeeperCP选举时不可用保证一致Redis ClusterAP主从切换时短暂不可用MySQL 主从AP主从延迟最终一致MongoDBCP单机模式可 CA集群模式 CPHBaseCP强一致金融级五、记忆口诀P 必选C 和 A 二选一网络一定会断所以 P 必须满足CP 强一致AP 高可用关键功能用 CP普通报表用 APCA 不是分布式是单机ZooKeeper / HBase CPEureka / Cassandra AP六、深入理解为什么 P 满足后 C 和 A 矛盾6.1 用两阶段提交举例2PC 协调者 参与者模型协调者 参与者 A 参与者 B ↓ ↓ ↓ prepare → vote yes vote yes ↓ ↓ ↓ 网络断参与者 A 收到 commit参与者 B 没收到 ↓ 协调者不知道参与者 B 的状态 ↓ ?这时候协调者只有 2 个选择选 C一致性协调者宁可卡住也不提交 ↓ 协调者等待网络恢复 ↓ 数据一致 ✅ 可用性 ❌业务卡住选 A可用性协调者直接放弃等待返回成功 ↓ 数据可能不一致参与者 A 提交了B 没提交 ↓ 数据一致 ❌ 可用性 ✅业务继续**所以 P 满足后C 和 A 在网络分区时一定是矛盾的。
CAP 定理：为什么不能同时实现 C、A、P？
一、CAP 是什么字母含义解释C**Consistency一致性所有节点同一时间看到的数据完全一致A**Availability可用性每个请求都能得到响应不保证数据最新P**Partition tolerance分区容错网络分区节点间通信失败时系统仍能继续工作二、为什么不能同时实现因为 P分区容错是分布式系统的前提条件**。网络分区一定可能发生断网、丢包、节点宕机。所以你必须在 C 和 A 之间二选一——这就是 CAP 的本质。2.1分布式系统必选 P为什么 P 必选分布式系统有多个节点节点间通过网络通信网络一定可能断网线被挖断、交换机故障、DNS 故障只要是分布式系统P 就必须满足2.2P 满足后C 和 A 只能二选一假设场景MySQL 主从集群主从之间网络断了主库 (192.168.1.1) ← 网络断 → 从库 (192.168.1.2) ↓ ↓ 写数据 w1 没收到情况 1选 C一致性——拒绝写主库检测到从库没收到 主库拒绝写入返回错误 主库保证数据一致主从都是空 ↓ ❌ 可用性没了用户写不进去情况 2选 A可用性——继续写主库不管从库先写入主库 主库返回写入成功 ↓ ✅ 可用性有了 ❌ 一致性没了主库有 w1从库没有**所以 P 满足后C 和 A 是互斥的——你必须牺牲一个。三、CAP 三选二的 3 种组合组合含义实际系统项目CA放弃 P单点系统不是分布式传统单机数据库MySQL 单机单库测试CP放弃 A强一致 分区容错可用性差ZooKeeper、etcd、HBase关键功能强一致AP放弃 C可用性 分区容错最终一致Eureka、Cassandra、Redis报表高可用⚠️ 关键点CA 不是真正的分布式单机就满足不分 P真实分布式只能在 CP 和 AP 之间选四、CAP 的扩展理解4.1CAP 不是三选一而是权衡老哥注意CAP 不是绝对的——不是非黑即白大部分系统在C 和 A 之间做权衡不是完全牺牲比如ZooKeeper 标榜 CP但实际写入失败后还会重试不是完全不可用4.2实际系统的 CAP 表现系统CAP实际表现EurekaAP节点挂了服务还能用不一致但可用Nacos 临时实例AP同 EurekaNacos 非临时实例CP网络断后不剔除保证一致ZooKeeperCP选举时不可用保证一致Redis ClusterAP主从切换时短暂不可用MySQL 主从AP主从延迟最终一致MongoDBCP单机模式可 CA集群模式 CPHBaseCP强一致金融级五、记忆口诀P 必选C 和 A 二选一网络一定会断所以 P 必须满足CP 强一致AP 高可用关键功能用 CP普通报表用 APCA 不是分布式是单机ZooKeeper / HBase CPEureka / Cassandra AP六、深入理解为什么 P 满足后 C 和 A 矛盾6.1 用两阶段提交举例2PC 协调者 参与者模型协调者 参与者 A 参与者 B ↓ ↓ ↓ prepare → vote yes vote yes ↓ ↓ ↓ 网络断参与者 A 收到 commit参与者 B 没收到 ↓ 协调者不知道参与者 B 的状态 ↓ ?这时候协调者只有 2 个选择选 C一致性协调者宁可卡住也不提交 ↓ 协调者等待网络恢复 ↓ 数据一致 ✅ 可用性 ❌业务卡住选 A可用性协调者直接放弃等待返回成功 ↓ 数据可能不一致参与者 A 提交了B 没提交 ↓ 数据一致 ❌ 可用性 ✅业务继续**所以 P 满足后C 和 A 在网络分区时一定是矛盾的。
