CAP 原则与 BASE 理论

刺骨的言语ヽ痛彻心扉 2022-09-11 04:24 284阅读 0赞

### 导航 ###

*  引言
 *  一、CAP 原则
 *   *  1.1 Consistency 一致性
     *  1.2 Available 可用性
     *  1.3 Partition tolerance 分区容错性
     *  1.4 CAP 的矛盾
     *  1.5 CAP 的组合场景
 *  二、BASE 理论
 *   *  2.1 基本可用
     *  2.2 软状态
     *  2.3 最终一致性
     *   *  2.3.1 因果一致性
         *  2.3.2 读自身所写
         *  2.3.3 会话一致性
         *  2.3.4 单调读一致性
         *  2.3.5 单调写一致性
 *  总结

# 引言 #

本文介绍CAP原则和BASE理论。二者是分布式系统中重要的参考原则及指导方针。

其中 CAP 是由加州大学的计算机科学家 Eric Brewer 于1998 年提出，代表了分布式系统的**三个重要指标**。

# 一、CAP 原则 #

CAP 是 Consistency 、Availability、Partition tolerance 的首字母缩写。所谓CAP原则，简单的说就是不可能存在CAP，即如下图所示，**CAP 三个指标只能实现其中两个，而永远无法三者兼具**。  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5Zyj5paX5aOrTW9ydHk_size_12_color_FFFFFF_t_70_g_se_x_16]

## 1.1 Consistency 一致性 ##

在系统中的所有数据备份，在同一时刻要保持同样的值。

## 1.2 Available 可用性 ##

在集群系统中，一部分节点故障后，集群整体依然可以响应外界请求。

简单来说，只要用户发起请求，系统就必须及时响应。**响应的越快，可用性越好**。

## 1.3 Partition tolerance 分区容错性 ##

分区指的是分布式系统中的多个网络节点之间无法通信，导致**分布在不同网络中的应用无法访问“失联的”数据**。

解决分区问题的最好办法就是给数据备份，备份在不同的网络中，这样，当网络通信出现故障，就会**降低数据访问不到的风险**，**提高了分区容错性**。

## 1.4 CAP 的矛盾 ##

一般来说，分区问题无法避免，只能采用备份数据的方式尽可能提高分区容错性。因此可以认为 CAP 中的 P 总是要具备的。**CAP 原则告诉我们，剩下的 C 和 A 无法兼得**。

简单来说，为了提高分区容错性，数据的备份是必要的，备份的数量越多，容错性越好，但备份的越多，保证一致性就越困难，也势必就影响系统整体的响应速度（可用性）。

但是，根据不同的业务场景，CAP 三者可以达到一种平衡关系。

## 1.5 CAP 的组合场景 ##

1.  **CA**：不允许分区的组合方式，舍弃了分区容错性。则 C （一致性）和 A（可用性）可以保证。但放弃 P 的同时也意味着放弃了系统扩展性，即限制分布式节点，这违背了分布式系统设计的初衷。满足CA 组合的系统例如传统的单体应用。
2.  **CP**：不要求 A（可用性），相当于数据需要保证较强的一致性。而 P （分区）会导致系统响应时间的延长，**一旦发生网络故障或消息丢失等情况，就要牺牲用户体验**。最典型的就是分布式系统，如传统数据库 MySQL，各种金融业务场景也需要优先保证CP指标，也可以算作是CP组合。
3.  **AP**：放弃一致性，追求更高的系统响应。一旦分区发生，节点之间的数据无法保持一致，为了高可用，每个节点只能使用本地数据提供服务。最典型的场景就是电商系统，同一个商品可能前一秒还库存充足，但秒杀一开始，刚准备下单，就提示下单失败，商品已售完。Redis也是一种AP分布式结构。

# 二、BASE 理论 #

BASE 是 Basically Available（基本可用）、Soft state（软状态）、Eventually Consistent（最终一致性）三个短语的缩写。

BASE 是对大规模互联网分布式系统的实践结论，**是对 CAP 中 C 一致性 和 A 可用性的权衡策略**。  
其**核心思想**是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

## 2.1 基本可用 ##

基本可用指的是，当系统出现故障，部分节点无法正常工作，可以允许牺牲一定程度的用户体验，但绝不允许系统完全不可用。

*  响应时间：正常情况，一个在线搜索引擎需要 0.5 秒内返回查询结果，但由于出现异常，查询时间增加到 1 ~ 2 秒。
 *  功能：正常情况，在一个电商系统购物，消费者几乎可以顺利完成每一笔订单，但是由于异常，或消费者数量激增，为了保证系统的稳定性，部分消费者可能会被引导到一个降级页面。

## 2.2 软状态 ##

什么是软状态呢？相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种“硬状态”。

软状态指的是：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即**允许系统在多个不同节点的数据副本存在数据延迟**。

## 2.3 最终一致性 ##

软状态允许数据备份延迟，但最终这些数据都要保证一致性。这就是最终一致性。

最终一致性在软状态上加了一个时限，这个时限取决于**网络延时、系统负载、数据复制方案设计**等。根据实际的业务场景，最终一致性可被分为以下 5 种。

### 2.3.1 因果一致性 ###

有果必有因。收到数据更新通知的节点，应该使用更新后的新值，即种下什么因，就得什么果。

例如，服务A更新了一个数据后，通知给了服务B，那么服务B如果要操作这个数据，应该使用 A 更新后的新值。如果 C 和 A没有这种关系，那么可以不受这一条件的限制。

### 2.3.2 读自身所写 ###

自身写入的新值，之后读取也应该是这个新值。这是一种特殊的因果一致性。

### 2.3.3 会话一致性 ###

会话一致性将对系统数据的访问过程**框定在了一个会话当中**：系统能保证在同一个有效的会话中实现“读自身所写”的一致性，也就是说，执行更新操作之后，客户端能够在同一个会话中始终读取到该数据项的最新值。

### 2.3.4 单调读一致性 ###

单调读一致性是指，如果一个节点从系统中读取出一个数据项的某个值后，那么系统对于该节点后续的任何数据访问都不应该返回更旧的值。

### 2.3.5 单调写一致性 ###

单调写一致性是指，一个系统要能够保证来自同一个节点的写操作被顺序的执行。

> **在实践中，这5种一致性往往会结合使用，以构建一个具有最终一致性的分布式系统**

# 总结 #

CAP 原则，分布式系统参考的三个重要指标。具体是指 **Consistency 一致性、Availability 可用性、Partition tolerance 分区容错性**。

CAP 原则指出，在一个分布式系统中，不可能同时满足三者，而分区容错性一般是必须具备的重要指标，这也是分布式系统的初衷，因此，实际的业务架构设计中，往往都是对 C 一致性 和 A 可用性的权衡和取舍。

三种类型组合的常见案例：

> 1、CA ：破坏了分布式系统的设计初衷，单体应用。  
> 2、CP ：传统数据库如 MySQL、各种涉及到银行、金融的交易系统。要求较高的一致性，舍弃用户体验。  
> 3、AP ：电商系统，秒杀等业务场景。但数据会实现最终一致性，追求用户体验的响应性，舍弃一部分实时的一致性，如 Redis 。

BASE 理论，是对CAP实践的进一步指导方针。是**基本可用、软状态、最终一致性**三个英文单词的缩写。

基本可用：顾名思义，即系统允许牺牲一部分用户体验，但决不允许系统无法响应，甚至崩溃。

软状态：允许系统中的备份数据存在中间状态，但也必须是不影响整体系统功能的前提下，即数据备份允许延迟。

最终一致性：在软状态之上增加了时限，要努力达到数据最终是一致的。5 种最终一致性：因果、读自写、会话、单调读、单调写。

[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA5Zyj5paX5aOrTW9ydHk_size_12_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/2c77731b54da46a9967cb2ebedc5c63b.png