CAP理论 与 BASE理论

一、分布式系统存在的问题

1.分布式系统

20世纪90年代，随着互联网应用的快速扩张，传统单机系统难以支撑高并发、跨地域的数据处理需求。分布式系统（Distributed System） 逐渐成为主流架构，分布式系统是由多台计算机（节点）通过网络连接协作组成的系统。这些节点分布在不同的物理位置，通过消息传递协调工作，对外表现为一个统一的整体。用户无需感知底层节点的分布细节，即可访问系统的功能或资源。

2.分区问题

分布式系统虽然成为了主流架构，但网络通信的不可靠性（如延迟、丢包、分区）依旧是其设计瓶颈。

网络分区（Network Partition） 指的是分布式系统中，由于网络故障（如交换机故障、光纤断裂、网络拥塞等），导致部分节点之间无法正常通信，整个系统被分割成多个独立的子网络（称为分区）。每个分区内的节点可以互相通信，但无法与其他分区的节点交换数据。

示例场景：

假设一个分布式数据库系统由3个节点（A、B、C）组成，部署在两个机房：
机房1：节点A、B
机房2：节点C

如果机房之间的网络突然中断（如光缆被挖断），节点A和B与节点C失去联系，系统被分割为两个独立的分区：
分区1：节点A、B（机房1）
分区2：节点C（机房2）

3.强一致性与高可用性的矛盾

在早期分布式系统中，设计者普遍采用ACID事务模型（强一致性），但在跨区域部署时，同步数据的延迟导致系统可用性下降。若坚持强一致性，系统响应速度会显著降低，影响用户体验。这就是 强一致性与高可用性的矛盾 。

本世纪初电商、社交等应用的需求激增。对高可用性。这些应用下用户对短暂数据不一致的容忍度较高，但对服务中断的容忍度极低。也就是说相比于强一致性，这些应用更加需要满足高可用性。

因此，需重新权衡一致性与可用性，以支持更灵活的架构设计。

二、CAP理论

在上述问题的基础上，加州大学伯克利分校的教授 埃里克·布鲁尔（Eric A. Brewer） 于2000年在分布式计算原理研讨会（PODC）上提出 CAP猜想，又被称作布鲁尔理论（Brewer’s theorem）。

2002年，麻省理工学院的 Seth Gilbert 和 Nancy Lynch 在文献《Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services》（DOI：10.1145/564585.564601）中发表了布鲁尔猜想的证明，CAP 理论正式成为分布式领域的定理。

1. CAP理论的核心概念

1. 一致性（Consistency） ：所有节点在同一时间访问相同的最新数据。写入操作后，任何读取都能立即获得最新值。
2. 可用性（Availability） ：每个请求都能获得响应（不保证数据最新），系统始终处于可操作状态。
3. 分区容错性（Partition Tolerance） ：系统在遭遇网络分区（节点间通信中断）时仍能继续运行。

2. CAP理论的核心观点

（1）CAP理论

CAP 也就是 Consistency（一致性）、Availability（可用性）、Partition Tolerance（分区容错性） 这三个单词首字母组合。

CAP理论指出对于一个分布式计算系统来说，不可能同时满足 Consistency（一致性）、Availability（可用性）、Partition Tolerance（分区容错性） 。

（2）CAP的权衡

网络分区发生时，系统必须在C和A之间选择：

CP（放弃A）：保证一致性和分区容忍性。当分区发生时，系统为了确保数据一致性，可能拒绝部分写操作或读操作，直到网络分区恢复。
AP（放弃C）：保证可用性和分区容忍性。当分区发生时，系统为了确保可用性，会继续响应请求，但是可能返回旧数据。
CA（放弃P）：仅在无分区的理想场景下可能实现，现实中的分布式系统通常无法完全避免分区，故CA系统罕见。

3. CAP误解修正

（1）CAP并非绝对三选二

1. CAP并非绝对三选二：仅在分区发生时强制权衡，正常情况可兼顾C和A。

在系统不存在分区的情况下没什么理由牺牲 C 或 A，所以正常情况可兼顾C和A。一句话概括：

当没有出现分区问题的时候，系统就应该有完美的数据一致性和可用性。

2. CAP并非绝对三选二：分区容错性 P 是一定要满足。

部分人常常简单将CAP理论理解为：“一致性、可用性、分区容忍性三者你只能同时达到其中两个，不可能同时达到”。实际上并不准确。

在 CAP 理论诞生 12 年之后，埃里克·布鲁尔在 2012 年重新发布了论文《CAP twelve years later: How the “rules” have changed》（DOI：10.1109/MC.2012.37）。论文中指出：

CAP 理论中分区容错性 P 是一定要满足的，在此基础上，只能满足可用性 A 或者一致性 C。

为什么说“分区容忍性（P）是必选项？

分布式系统的本质：分布式系统由多个节点组成，节点间必然存在网络通信，而网络故障是物理世界的常态（如光纤损坏、路由器宕机）。无法保证网络永远可靠，因此必须设计系统应对分区。

（2）C/A 权衡并非针对整个分布式系统，而是按需细化

CAP理论中一致性（C）与可用性（A）的取舍并非系统级强制绑定，而是可针对不同模块或数据类型局部动态决策。以支付系统为例：
账户余额、交易流水等金融核心数据，需确保跨节点强一致（CP）；
会员名称、支付偏好等非关键信息，允许分区期间返回旧值以优先服务可用性（AP）。

设计核心：基于业务价值与风险，为不同数据单元定义独立的一致性等级，实现精细化权衡。

（3）CAP 的三个特性不是只有和否两种极端选择，非二元对立

CAP理论中C/A/P 并不是非true即false的布尔选项，而是连续可调的权衡维度。
可用性显然是在 0% 到 100% 之间连续变化的，一致性分很多级别，分区也可以细分为不同含义。

4. CP 与 AP

根据上述理论可以得出，对于分布式系统，我们只能能考虑当发生分区错误时，如何选择一致性和可用性。

（1）实际应用

1. CP系统： 如金融系统，确保数据准确但可能牺牲可用性。
2. AP系统： 如社交平台，允许短暂不一致，通过同步机制最终达成一致。

（2）开源案例分析

1. CP系统： ZooKeeper、HBase。分区时拒绝写入，确保数据强一致。

2. AP系统： Eureka 、Cassandra、Dynamo。分区时继续响应，可能返回旧数据，后续解决冲突。

3. Nacos 不仅支持 CP 也支持 AP

5.CAP理论文献引用

1. Gilbert S, Lynch N. Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services[J]. Acm Sigact News, 2002, 33(2): 51-59.
2. Brewer E. CAP twelve years later: How the" rules" have changed[J]. Computer, 2012, 45(2): 23-29.

三、BASE理论

1. BASE理论简介

eBay 的架构师 Dan Pritchett 与2008年在 ACM 上发表《BASE: An Acid Alternative: In partitioned databases, trading some consistency for availability can lead to dramatic improvements in scalability.》提出了BASE理论（DOI: 10.1145/1394127.1394128）。

BASE 是 Basically Available（基本可用）、Soft-state（软状态） 和 Eventually Consistent（最终一致性） 三个短语的缩写。BASE 理论是对 CAP 中一致性 C 和可用性 A 权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于 CAP 定理逐步演化而来的。

2. BASE理论的前置知识

（1）分布式一致性的 3 种级别

1. 强一致性（Strong Consistency）： 所有节点的数据实时同步，任何读取操作都能获取最新写入的数据。主要应用于金融交易、账户余额、库存扣减等不允许数据不一致的业务。
2. 弱一致性（Weak Consistency： 不保证数据实时同步，读取可能返回旧值，系统优先保证可用性。主要应用于社交动态、新闻推送、评论系统等可容忍短暂不一致的业务。
3. 最终一致性（Eventual Consistency）： 弱一致性的特例，系统保证若无新写入，经过一段时间后所有副本终将一致。主要应用于用户个人信息、配置数据、分布式缓存等可接受短期不一致但最终需一致的业务。

对比：

一致性级别	特点	常用情况举例	实现方式
强一致性	数据错误会导致严重后果	金钱、医疗数据	同步复制、分布式锁、共识算法
最终一致性	可接受短暂不一致，但最终需一致	用户昵称	读时修复、写时修复、异步修复
弱一致性	不一致对业务影响极小	新闻阅读数	异步复制

（2）损失部分可用性的一些方式：

• 服务降级（Degradation）： 当系统负载过高或部分功能不可用时，系统的部分非核心功能无法使用，优先保障核心业务。例如：电商大促时，关闭商品详情页的“用户评价”功能，确保下单流程正常。
• 流量控制（Throttling）： 通过限流、排队等方式，避免系统被突发流量击垮。例如12306 火车票系统在抢票时采用排队机制，而非直接拒绝请求。
• 数据兜底（Fallback）： 当实时数据不可用时，返回缓存或默认数据。例如推荐系统在计算引擎超时后，返回热门榜单而非个性化推荐。

3. BASE理论思想

BASE理论的核心思想是即使无法达到强一致性，也可以通过设计来达到最终一致性‌。

• 基本可用（Basically Available）： 系统在出现部分故障时，允许损失部分可用性，仍然能够提供有限的服务能力，而不是完全不可用。
• 软状态（Soft-state）： 系统允许数据存在中间状态（即软状态），不要求所有节点时刻保持强一致，而是通过异步方式最终同步。
• 最终一致性（Eventually Consistent）： 系统不保证数据的实时一致性，但经过一段时间（可能是几秒、几分钟甚至更长）后，所有副本最终会达成一致。

总结：
BASE 理论面向的是大型高可用可扩展的分布式系统，和传统事务的 ACID 是相反的，它完全不同于 ACID 的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间是不一致的。