分布式cap base

分布式CAP与BASE理论：面试必考点精讲与实战拆解

大家好，我是程序员老王。今天咱们来聊聊分布式系统面试中绕不过去的经典问题：CAP定理和BASE理论。理解这两个概念，对设计高可用、可扩展的系统至关重要。文末有福利，记得看到最后！

【2025年Java面试宝典抢先看！】
链接: https://pan.baidu.com/s/1RUVf75gmDVsg8MQp4yRChg?pwd=9b3g 提取码: 9b3g
（覆盖分布式、高并发、微服务等高频考点）

一、CAP定理：分布式系统的三角困境

CAP定理（Consistency, Availability, Partition tolerance）是分布式系统的基石理论。它指出：在网络分区（Partition tolerance）不可避免的情况下，系统只能在一致性（C） 和可用性（A） 中二选一。

面试高频题解：

P必须保障：网络分区是客观存在（如机房断网），P是必须选项。
CP系统（如Etcd、ZooKeeper）：
- 牺牲可用性：分区发生时拒绝写入，保证数据强一致。
- 场景：金融交易、配置中心。
AP系统（如Cassandra、Eureka）：
- 牺牲一致性：分区时允许读写，但数据可能短暂不一致。
- 场景：社交feed流、实时监控。

关键结论：没有完美的CAP系统，需根据业务场景权衡。

二、BASE理论：对CAP的实践补充

当系统选择AP方向时，如何兼顾业务可接受的一致性？ BASE理论应运而生：

Basically Available（基本可用）：核心功能必须可用（如降级策略）。
Soft State（软状态）：允许中间态存在（如订单"处理中"）。
Eventually Consistent（最终一致）：数据异步同步达成一致。

实战案例：

电商库存扣减：
1. 用户下单 → 预扣缓存库存（软状态）
2. 消息队列异步更新DB（最终一致）
3. 超卖时补偿退款（基本可用）

三、面试经典问题拆解

问题1：为什么ZooKeeper是CP系统？

答：

写操作需半数以上节点ACK（强一致）
Leader选举期间拒绝服务（牺牲A）
适用场景：分布式锁、选主

问题2：BASE如何解决数据冲突？

答：

版本向量（Version Vector）标记数据版本
CRDTs（无冲突复制数据类型）自动合并
人工兜底（如客服介入）

四、技术选型建议

| 场景 | 推荐技术 | CAP倾向 | |---------------------|------------------------|---------| | 支付交易 | TiDB, Google Spanner | CP | | 高并发读缓存 | Redis Cluster | AP | | 服务注册发现 | Nacos, Eureka | AP | | 分布式配置中心 | ZooKeeper, Consul | CP |