PorterYuan · 个人学习博客

CAP 理论 + BASE 理论

15分钟阅读

CAP 理论 + BASE 理论

CAP 理论是分布式系统的”物理定律”——你不能同时拥有一切。BASE 理论是 CAP 的”务实妥协”——既然强一致太贵，那就退一步追求”最终一致”。理解这两个理论，是回答所有分布式题的底层框架。

一、CAP 理论

1.1 三个要素


graph TD

    C[ C - Consistency<br/>一致性 ] --- A[ A - Availability<br/>可用性 ]

    A --- P[ P - Partition Tolerance<br/>分区容错性 ]

    P --- C

    style C fill:#e63946 color:#fff

    style A fill:#2a9d8f color:#fff

    style P fill:#264653 color:#fff
要素含义生活类比
C（一致性）所有节点同一时刻看到的数据完全一样你在北京改了银行余额，上海的 ATM 必须立刻显示新余额
A（可用性）每个请求都能得到非错误响应（不保证是最新数据）ATM 机随时能取钱，不会告诉你”稍后再试”
P（分区容错性）网络分区（部分节点失联）时系统仍能运行公司内网断了，各部门还能独立办公

1.2 为什么只能三选二？


graph TD

    subgraph "网络分区发生时"

        N1[ 节点N1 数据 D1=100 ] -.->|网络断了| N2[ 节点N2 数据 D2=100 ]

    end

    User1[ 用户A 写入N1 D1变200 ] --> N1

    User2[ 用户B 读取N2 ] --> N2

    Choice1[ 方案C: N2拒绝响应等同步<br/>可用性损失 ]

    Choice2[ 方案A: N2立即返回旧值<br/>一致性破坏 ]

    N1 --> Choice1

    N1 --> Choice2

    style Choice1 fill:#e63946 color:#fff

    style Choice2 fill:#2a9d8f color:#fff

推导过程：

  1. 网络分区不可避免 → P 必须保证（分布式系统的基本要求）

  2. 分区发生时，节点间无法同步数据

  3. 要强一致性（C）→ 必须等同步完成再响应 → 可用性（A）受损

  4. 要可用性（A）→ 立即用本地数据响应 → 数据可能不一致 → 一致性（C）受损

  5. 所以 P 固定的前提下，C 和 A 二选一

1.3 三种组合与代表系统


graph TD

    subgraph "CA - 放弃分区容错"

        CA[ 传统单机数据库<br/>MySQL单实例<br/>同一机房内 ]

    end

    subgraph "CP - 放弃可用性"

        CP[ 强一致性系统<br/>ZooKeeper<br/>Redis Cluster<br/>HBase ]

    end

    subgraph "AP - 放弃一致性"

        AP[ 高可用系统<br/>Eureka<br/>Cassandra<br/>DynamoDB ]

    end

    CA -->|现实中几乎不存在| Note[ 网络分区不可避免<br/>CA只是理论模型 ]

    CP -->|适合金融| CP_Used[ 转账/支付<br/>宁可不可用也不能数据错 ]

    AP -->|适合互联网| AP_Used[ 电商/社交<br/>短暂不一致可接受 ]

    style CA fill:#999 color:#fff

    style CP fill:#e63946 color:#fff

    style AP fill:#2a9d8f color:#fff
组合放弃什么代表系统适用场景
CA放弃 P（理论模型）单机 MySQL现实中几乎不存在
CP放弃 A（宁可不可用）ZooKeeper、Redis Cluster、HBase、MongoDB金融转账、分布式锁
AP放弃 C（允许暂时不一致）Eureka、Cassandra、DynamoDB、DNS电商下单、社交动态

关键：现实中 P 不可避免，所以真正的问题是”CP 还是 AP”——不是”三选二”，而是”在 C 和 A 之间选一个”。

1.4 CAP 的常见误解

误解正确理解
”CAP 是三选二”实际是 P 必须保，C 和 A 二选一
”选了 CP 就完全不可用”只是分区时部分请求被拒绝，不是完全停服
”选了 AP 就完全不一致”只是分区时短暂不一致，分区恢复后最终一致
”CAP 适用于所有场景”CAP 描述的是分区期间的行为，非分区期间可以同时满足 C 和 A

二、BASE 理论

BASE 是对 CAP 中 AP 方案的扩展——既然放弃强一致性，那怎么在”最终一致”的前提下保证系统可用？

2.1 三个要素


graph LR

    BA[ BA - Basically Available<br/>基本可用 ] --> SS[ SS - Soft State<br/>软状态 ]

    SS --> EC[ EC - Eventually Consistent<br/>最终一致性 ]

    style BA fill:#f4a261 color:#000

    style SS fill:#2a9d8f color:#fff

    style EC fill:#264653 color:#fff
要素含义生活类比
BA（基本可用）系统出现故障时，允许损失部分功能，核心功能仍可用超市大促：结账排队变长（响应变慢），但还能买东西（核心功能）
SS（软状态）允许数据存在中间状态，不影响整体可用性外卖已下单但还没配送——“处理中”就是软状态
EC（最终一致性）经过一段时间后，所有数据副本达到一致转账后对方晚几秒收到——但最终一定收到

2.2 BASE 的具体表现


graph TD

    subgraph "基本可用(BA)的表现"

        BA1[ 功能降级: 大促时关闭推荐功能<br/>保住核心下单流程 ]

        BA2[ 响应变慢: 查询从50ms变成200ms<br/>但不报错 ]

        BA3[ 流量削峰: 排队等待<br/>而不是直接拒绝 ]

    end

    subgraph "软状态(SS)的表现"

        SS1[ 订单状态: 待支付→已支付→已发货<br/>中间态-处理中-对外可见 ]

        SS2[ 库存: 扣减和确认之间有延迟<br/>但业务可继续 ]

    end

    subgraph "最终一致性(EC)的表现"

        EC1[ 支付成功后: 积分延迟3秒到账<br/>但最终一定到账 ]

        EC2[ 缓存更新: DB更新后缓存异步刷新<br/>短暂读到旧值 ]

    end

    style BA1 fill:#f4a261 color:#000

    style SS1 fill:#2a9d8f color:#fff

    style EC1 fill:#264653 color:#fff

2.3 最终一致性的五种实现方式

方式原理典型应用
本地消息表本地事务写业务+消息表，定时轮询投递 MQ订单→积分/优惠券通知
事务消息RocketMQ 半消息+本地事务支付回调
可靠消息MQ + 重试 + 死信队列服务间异步通知
最大努力通知定时回调+对账支付平台→商户回调
TCC/Saga业务层补偿跨服务事务

三、CAP 与 BASE 的关系


graph TD

    CAP[ CAP 理论<br/>分布式系统的物理定律<br/>三选二实际CA二选一 ] -->|选AP可用性优先| BASE[ BASE 理论<br/>AP方案的实践指南<br/>如何在放弃强一致后仍保证系统可用 ]

    CAP -->|选CP一致性优先| StrongCP[ 强一致性方案<br/>2PC / XA / Paxos<br/>牺牲可用性换数据准确 ]

    BASE -->|三要素| BA[ 基本可用 ]

    BASE -->|三要素| SS[ 软状态 ]

    BASE -->|三要素| EC[ 最终一致性 ]

    style CAP fill:#e63946 color:#fff

    style BASE fill:#2a9d8f color:#fff

    style StrongCP fill:#264653 color:#fff
维度CAPBASE
定位理论定律（描述客观限制）实践指南（如何在限制下设计）
回答的问题”分布式系统能做什么？""不能强一致时怎么办？“
适用阶段架构选型（选 CP 还是 AP）具体实现（AP 方案的设计原则）
核心矛盾C 和 A 不可兼得用 BA + SS + EC 弥补 C 的损失

回答框架：CAP 解决”选哪条路”（CP vs AP），BASE 解决”选了 AP 后怎么走”（基本可用 + 软状态 + 最终一致）。

四、经典系统 CAP 选型一览

系统选型为什么
ZooKeeperCP分布式协调需要强一致，宁可短暂不可用
EurekaAP服务发现需要高可用，短暂不一致可接受
NacosCP/AP 可切换服务发现用 AP，配置中心用 CP
Redis ClusterCP数据分片需要一致性保证
CassandraAP高可用写入优先，最终一致
MySQL 单机CA无网络分区时同时满足 C 和 A
MongoDBCP（默认）默认强一致，可配置为 AP

五、延伸追问

Q1：CAP 理论的核心是什么？

分布式系统最多同时满足一致性（C）、可用性（A）、分区容错性（P）中的两个。由于网络分区不可避免（P 必须保），实际是在 C 和 A 之间做权衡——选 CP（如 ZooKeeper）还是 AP（如 Eureka）。

Q2：为什么说”CAP 是三选二”是错误的？

严格来说是”P 必须保，C 和 A 二选一”。CA 组合理论上要求放弃分区容错，但网络分区在分布式系统中不可避免，所以 CA 只是理论模型，现实中的选择是 CP 还是 AP。

Q3：BASE 理论是什么？和 CAP 什么关系？

BASE 是对 CAP 中 AP 方案的扩展——基本可用（BA）：允许损失部分功能；软状态（SS）：允许中间状态存在；最终一致性（EC）：经过一段时间后数据达到一致。CAP 决定”选哪条路”，BASE 解决”选了 AP 后怎么走”。

Q4：强一致性和最终一致性的区别？

强一致性：写操作完成后，任何后续读操作都能读到最新值（如银行转账）。代价是性能低、可用性差。最终一致性：写操作完成后，允许短暂读到旧值，但经过一段时间（毫秒~秒级）后所有副本达到一致。代价是可能读到过期数据，但性能和可用性好。

Q5：Eureka 为什么选 AP 不选 CP？

服务发现场景下，可用性比一致性更重要——如果注册中心不可用，所有微服务都无法互相调用，整个系统瘫痪。短暂返回过期的服务列表（AP）比完全不可用（CP）好得多。ZooKeeper 选 CP 是因为分布式协调（如选主）需要强一致。

一句话总结

CAP = 分布式系统的物理定律：P 必须保，C 和 A 二选一。CP 适合金融（ZooKeeper），AP 适合互联网（Eureka）。BASE = AP 方案的实践指南：基本可用 + 软状态 + 最终一致性。学习重点：CAP 真正含义是”C/A 二选一”而非”三选二”、BASE 三要素的含义、经典系统的 CP/AP 选型。

速记卡（面试闪卡）

Q1：一句话讲清「CAP 理论 + BASE 理论」到底是什么？

A：CAP 与 BASE 是分布式系统的底层框架：CAP 说分区下 C/A 二选一，BASE 是 AP 方案的务实妥协。

Q2：一、CAP 理论 —— 怎么理解？

A：像小区三项基建：C 一致性（所有节点数据同刻一致）、A 可用性（每个请求都有响应）、P 分区容错（断网仍能跑）。网络分区不可避免，所以 P 必保，真实是在 C 和 A 间二选一。CAP Theorem（CAP 定理）。

Q3：二、BASE 理论 —— 怎么理解？

A：像 AP 方案的补丁：BA 基本可用（故障丢部分功能保核心）、SS 软状态（允许中间态）、EC 最终一致（过一阵全副本一致）。是对 CAP 中放弃强一致后的实践指南。BASE Theory（BASE 理论）。

Q4：三、CAP 与 BASE 的关系 —— 怎么理解？

A：像路线与走法：CAP 解决“选哪条路”（CP 还是 AP），BASE 解决“选了 AP 后怎么走”（基本可用+软状态+最终一致）。前者是理论定律，后者是落地指南。CP vs AP（一致性与可用性权衡）。

Q5：四、经典系统 CAP 选型一览 —— 怎么理解？

A：像按场景挑配置：ZooKeeper/Redis Cluster 选 CP（金融强一致宁可不可用），Eureka/Cassandra 选 AP（高可用短暂不一致可接受），Nacos 可切 CP/AP，MySQL 单机算 CA。CP / AP Selection（CAP 选型）。

Q6：核心速记主线有哪些？

  • CAP：P 必保，C 与 A 二选一，非真三选二

  • BASE：BA 基本可用、SS 软状态、EC 最终一致

  • 关系：CAP 选路，BASE 走 AP 实践指南

  • 选型：金融 CP（ZooKeeper），互联网 AP（Eureka）

口诀

A：CAP 物理定律强，P 必保留 C A 选

金融要稳选 CP，互联要高选 AP

BASE 三要素补齐，最终一致保可用

选路走法两步走，分布式题底框架

相关链接

关系图谱

反向链接

近期更新