分布式系统 CAP 与 Base 理论详解

今天记录分享下系统架构设计，搞懂分布式系统的核心理论——CAP 与 Base，全文干货满满，希望对大家有所帮助。

一、CAP 理论

分布式系统的“三角难题”

CAP 理论是加州大学伯克利分校 Eric Brewer 教授在 2000 年提出的，它揭示了分布式系统的三个核心特性无法同时满足，这也是分布式架构设计的“第一原则”。

（一）CAP 三个特性？

很多文章把 CAP 讲得太抽象，其实用电商场景一举例就明白：

• C（Consistency）- 一致性：所有节点的数据完全一致。比如用户买了一件库存 10 件的商品，不管访问哪个服务器，都应该显示库存 9 件，不能出现“甲服务器显示 9 件，乙服务器显示 10 件”的情况。

• A（Availability）- 可用性：服务始终能正常响应。比如秒杀活动时，即使并发再高，用户访问库存服务也不会出现“502 错误”或“超时”，至少能得到“请求成功”或“库存不足”的明确反馈。

• P（Partition Tolerance）- 分区容错性：节点间网络故障时，系统仍能工作。比如北京和上海的服务器之间断网了，北京的用户还能正常访问本地服务，上海的用户也不受影响。

CAP	描述
C 一致性	Consistency，一致性 强调的是 分布式系统中各个节点之间的数据一致性；不管访问哪个节点，返回的数据都是一致的，否则节点不可用（拒绝服务）
A 可用性	Availability，可用性 强调的是 分布式系统中各个节点都能正常被访问，正常响应请求，但是无法保证 返回数据的一致性：也就是各个节点正常访问但是节点之间数据不一定一致
P 分区容错性	Partition tolerance，节点网络故障，不可避免，当节点间出现任意数量的消息丢失或高延迟（网络障碍）的时候，系统仍然可以继续提供服务

分布式系统中 P（分区容错性）是必须满足的（网络故障无法避免），所以实际架构只能在 C 和 A 中做权衡，也就是“CP”或“AP”架构。

（二）为什么 CAP 不能同时满足？

可能的组合如下：

组合	描述
CA	一致性 + 可用性，不存在，P 一定得有，分布式系统下，网络故障网络延迟必然存在，
CP	一致性 + 分区容错性；数据强一致性，返回的都是绝对一致的数据，不一致的时候会读取失败（拒绝提供服务）
AP	可用性 + 分区容错性：服务高可用，但是不能保证数据一致性，要保证数据一致性，服务就不一定可用

在分布式系统中，节点与节点之间通过网络通信，网络通信必然存在：网络延迟、网络故障；

因此 CAP 中，P （分区容错性）必须存在，其次，CA 不可能同时存在，因为分布式系统下，数据同步存在延迟，无法实时一致性，存在某一刻不一致，那么数据不一致的情况下：

● 节点要么满足 C，数据不一致，拒绝服务

● 节点要么满足 A，服务可用，但是数据不一致

综上所述：P 必须，C 和 A 只能选一个，也就是 组合： CP、AP

（三）CP 还是 AP？

没有绝对的“更好”，只有“更合适”，两个架构的选型直接决定系统的稳定性：

选 CP 架构的场景：数据一致性优先

适合金融、支付、库存等不允许数据出错的场景。

比如银行转账，必须保证转出和转入金额一致，即使短暂无法访问也不能出现“钱扣了没到账”的情况。

典型案例：ZooKeeper、etcd。

这类组件在节点故障时，会先选举主节点再提供服务，选举期间服务暂时不可用（牺牲 A），但保证数据一致（满足 C）。

选 AP 架构的场景：服务可用性优先

适合电商、社交、资讯等用户体验优先的场景。比如电商商品详情页，即使不同用户看到的库存有 1 - 2 秒延迟，也比打不开页面好；再比如微信朋友圈，偶尔刷不出最新动态，用户能接受，但 app 崩了就不行。

典型案例：Redis 集群、ElasticSearch。

这类组件在节点故障时，立刻切换到备用节点提供服务（满足 A），允许数据短暂不一致（牺牲 C），后续再通过同步机制恢复一致。

二、Base 理论

很多人选了 AP 架构后又犯愁：“允许数据不一致，但多久能一致？怎么控制？

”Base 理论就是为解决这个问题而生的，它是 CAP 理论中 AP 方向的延伸，告诉我们如何在保证可用性的前提下，让数据“最终一致”。

Base 是“Basically Available（基本可用）”“Soft State（软状态）”“Eventually Consistent（最终一致）”的缩写，同样用场景解释：

• 基本可用：不追求“100% 可用”，但要保证核心功能可用。比如秒杀时，为了抗并发，暂时屏蔽“商品评价”“收藏”等非核心功能，只保留“下单”“支付”核心功能；再比如服务器负载过高时，对部分请求限流，返回“稍等再试”而非直接崩溃。

• 软状态：允许数据存在“中间状态”，且不影响系统可用性。比如电商下单后，会有“待支付”状态；外卖订单有“商家接单中”状态，这些中间状态就是软状态，系统不需要立刻让所有节点同步这个状态。

• 最终一致：所有数据最终会在一定时间内同步一致，不需要实时一致。比如 Redis 集群的“主从同步”，主节点写入数据后，从节点会在几十毫秒内同步，这个过程中主从数据不一致，但最终会一致；再比如支付宝转账，跨银行转账可能需要 10 分钟到账，这就是最终一致。

CAP 规则下 AP 模型 的延伸，AP + Base，实现 服务高可用 + 数据最终一致性

最终一致性：也就是允许节点之间的数据出现短暂的数据不一致情况，但是节点高可用

目前 Redis 采用的分布式理论就是 CAP + Base：

redis 采用的是 AP + Base 模型，也就是满足 分区容错性 和 服务高可用 ，保证数据的最终一致性

常见问题

Q1：有没有办法同时满足 CAP 三个特性？

没有。因为分布式系统必然面临网络分区（P 必须满足），而 C 和 A 是矛盾的——要保证所有节点数据一致，就需要等待同步完成，期间服务不可用；要保证服务随时可用，就只能返回本地数据，无法保证一致。只有单体系统能同时满足，但单体系统不是分布式系统。

Q2：Base 理论和 CAP 理论是什么关系？

Base 是 CAP 理论的“子集落地方案”。

CAP 告诉我们“AP 架构可行”，但没说怎么实现；Base 则明确了 AP 架构的实现思路——通过“基本可用”保证 A，通过“软状态”和“最终一致”解决 C 的问题，让理论落地。

Q3：如何判断自己的系统该选 CP 还是 AP？

核心看“数据错误的代价”和“服务不可用的代价”哪个更高：

• 如果数据错误会导致资金损失、法律风险（比如支付、金融），选 CP；

• 如果服务不可用会导致大量用户流失、收入下降（比如电商、社交），选 AP。

也可以“混合架构”：核心模块选 CP（比如订单支付），非核心模块选 AP（比如商品推荐）。

Q4：最终一致的“最终”是多久？怎么控制？

没有固定标准，根据业务场景定义。比如：

• 电商库存同步：要求 1 - 5 秒内一致，避免超卖；

• 用户积分同步：允许 1 - 2 分钟内一致，用户感知不强；

• 数据备份同步：允许几小时内一致，只要不影响故障恢复即可。

控制方式：通过同步频率（如示例中的 5 秒）、同步机制（如主从复制、消息队列异步同步）调整，频率越高、机制越可靠，“最终”的时间越短。

总结

CAP 和 Base 理论不是“纸上谈兵”的理论，而是分布式架构的“决策指南”。

重点：

第一，分布式系统必选 P，所以只能在 C 和 A 中选；

第二，CP 保数据一致，AP 保服务可用，根据业务代价选型；

第三，Base 是 AP 的落地方法，核心是“最终一致”。。

如果大家在理论选型或落地时遇到具体问题，欢迎在评论区交流～