CAP 理论与 BASE 理论¶

类比：分布式系统的"不可能三角"¶

就像"便宜、好、快"三者只能选两个，分布式系统中"一致性、可用性、分区容错性"也只能同时满足两个。

CAP 三要素¶

flowchart TD
    CAP((CAP 理论))
    C[一致性 Consistency\n所有节点同一时刻\n看到相同数据]
    A[可用性 Availability\n每个请求都能\n收到响应(不保证最新)]
    P[分区容错性 Partition Tolerance\n网络分区时\n系统仍能运行]

    CAP --> C
    CAP --> A
    CAP --> P

    C -.->|三者只能\n同时满足两个| A
    A -.-> P
    P -.-> C

为什么 CAP 不可兼得？¶

分布式系统中，网络分区（P）是必然发生的（网络不可靠），因此实际上只能在 C 和 A 之间做取舍：

CP 系统：保证一致性，牺牲可用性。网络分区时，宁可拒绝请求也不返回旧数据。
AP 系统：保证可用性，牺牲一致性。网络分区时，返回可能过时的数据，但不拒绝请求。

为什么 P 不可放弃：分布式系统中，网络分区是客观存在的（网络抖动、机器宕机），无法避免。因此 P 是前提，只能在 C 和 A 之间权衡。

常见系统的 CAP 选择¶

系统	类型	原因	适用场景
MySQL（单机）	CA	单机无网络分区问题	单机 OLTP
MySQL（主从）	CP	主库宕机时从库不提供写服务	需要强一致性的业务
ZooKeeper	CP	Leader 选举期间不可用，但数据强一致	配置中心、分布式锁
Redis Cluster	AP	主节点宕机时副本可能数据不一致，但仍可用	缓存、会话存储
Eureka	AP	节点间同步失败时仍提供服务发现	服务注册发现
Nacos	CP/AP 可配置	注册中心用 AP，配置中心用 CP	微服务基础设施
Elasticsearch	AP	优先可用性，允许短暂不一致	搜索、日志分析

BASE 理论（CAP 的工程实践）¶

BASE：Basically Available（基本可用）+ Soft State（软状态）+ Eventually Consistent（最终一致性）

核心思想：不追求强一致性，允许数据在一段时间内不一致，但最终会达到一致状态。

工程实践： - 订单支付后，库存扣减通过消息队列异步处理（最终一致） - 用 Redis 缓存用户信息，允许短暂与 DB 不一致（软状态）

面试高频问题¶

Q：CAP 理论中，为什么 P 不可放弃？

分布式系统中，网络分区是客观存在的（网络抖动、机器宕机），无法避免。因此 P 是前提，只能在 C 和 A 之间权衡。

Q：CAP 选型常见错误？

强一致性场景（如金融转账）选了 AP 系统，导致数据不一致。应根据业务需求选择 CP 或 AP。