【分布式】——CAP&BASE理论

CAP&BASE理论

⭐⭐⭐⭐⭐⭐

Github主页👉https://github.com/A-BigTree

笔记链接👉https://github.com/A-BigTree/tree-learning-notes

⭐⭐⭐⭐⭐⭐

Spring专栏👉https://blog.csdn.net/weixin_53580595/category_12279588.html

SpringMVC专栏👉https://blog.csdn.net/weixin_53580595/category_12281721.html

Mybatis专栏👉https://blog.csdn.net/weixin_53580595/category_12279566.html

如果可以，麻烦各位看官顺手点个star~😊

如果文章对你有所帮助，可以点赞👍收藏⭐支持一下博主~😆

文章目录

CAP&BASE理论
- [1 理解CAP](#1 理解CAP)
- - [1.1 C-Consistency](#1.1 C-Consistency)
  - [1.2 A-Availability](#1.2 A-Availability)
  - [1.3 P-Partition tolerance](#1.3 P-Partition tolerance)
- [2 CAP组合方式](#2 CAP组合方式)
- - [2.1 AP](#2.1 AP)
  - [2.2 CP](#2.2 CP)
  - [2.3 CA](#2.3 CA)
- [3 BASE理论](#3 BASE理论)
- - [3.1 强一致性和最终一致性](#3.1 强一致性和最终一致性)
  - [3.2 BASE理论介绍](#3.2 BASE理论介绍)
  - - [3.2.1 基本可用](#3.2.1 基本可用)
    - [3.2.2 软状态](#3.2.2 软状态)
    - [3.3.3 最终一致](#3.3.3 最终一致)

1 理解CAP

CAP 是 Consistency、Availability、Partition tolerance 三个单词的缩写，分别表示一致性 、可用性 、分区容忍性。

结合电商系统中的一些业务场景来理解CAP，对于商品服务写入主从数据库集群的情况，整体执行流程如下：

商品服务请求主数据库写入商品信息（添加商品、修改商品、删除商品）；
主数据库向商品服务响应写入成功；
商品服务请求从数据库读取商品信息；

1.1 C-Consistency

一致性是指写操作后的读操作可以读取到最新的数据状态，当数据分布在多个节点上，从任意结点读取到的数据都是最新的状态。

在该业务场景中，商品信息的读写要满足一致性就是要实现如下目标：

商品服务写入主数据库成功，则向从数据库查询新数据也成功；
商品服务写入主数据库失败，则向从数据库查询新数据也失败；

如何实现一致性？

写入主数据库后要将数据同步到从数据库；
写入主数据库后，在向从数据库同步期间要将从数据库锁定，待同步完成后再释放锁，以免在新数据写入成功后，向从数据库查询到旧的数据；

分布式系统一致性的特点：

由于存在数据同步的过程，写操作的响应会有一定的延迟；
为了保证数据一致性会对资源暂时锁定，待数据同步完成释放锁定资源；
如果请求数据同步失败的结点则会返回错误信息，一定不会返回旧数据；

1.2 A-Availability

可用性是指任何事务操作都可以得到响应结果，且不会出现响应超时或响应错误。

在该场景中，商品信息读取满足可用性就是要实现如下目标：

latex 复制代码

1. 从数据库接收到数据查询的请求则立即能够响应数据查询结果。
2. 从数据库不允许出现响应超时或响应错误。

如何实现可用性

latex 复制代码

1. 写入主数据库后要将数据同步到从数据库。
2. 由于要保证从数据库的可用性，不可将从数据库中的资源进行锁定。
3. 即时数据还没有同步过来，从数据库也要返回要查询的数据，哪怕是旧数据，如果连旧数据也没有则可以按照约定返回一个默认信息，但不能返回错误或响应超时。

分布式系统可用性的特点：所有请求都有响应，且不会出现响应超时或响应错误

1.3 P-Partition tolerance

通常分布式系统的各各结点部署在不同的子网，这就是网络分区，不可避免的会出现由于网络问题而导致结点之间通信失败，此时仍可对外提供服务，这叫分区容忍性。

在该场景中，商品信息读写满足分区容忍性就是要实现如下目标：

latex 复制代码

1. 主数据库向从数据库同步数据失败不影响读写操作。
2. 其一个结点挂掉不影响另一个结点对外提供服务。

如何实现分区容忍性？

latex 复制代码

1. 尽量使用异步取代同步操作，例如使用异步方式将数据从主数据库同步到从数据，这样结点之间能有效的实现松耦合。
2. 添加从数据库结点，其中一个从结点挂掉其它从结点提供服务。

分布式分区容忍性的特点：分区容忍性分是布式系统具备的基本能力

2 CAP组合方式

上边商品管理的例子是否同时具备 CAP 呢？

在所有分布式事务场景中不会同时具备 CAP 三个特性，因为在具备了P的前提下C和A是不能共存的

比如该例子满足分区容忍，该例中分区容忍的含义是：

主数据库通过网络向从数据库同步数据，可以认为主从数据库部署在不同的分区，通过网络进行交互。
当主数据库和从数据库之间的网络出现问题不影响主数据库和从数据库对外提供服务。
其中一个节点挂掉不影响另一个节点对外提供服务。

如果要实现 C 则必须保证数据一致性，在数据同步的时候为防止向从数据库查询不一致的数据则需要将从数据库数据锁定，待同步完成后解锁，如果同步失败从数据库要返回错误信息或超时信息。

如果要实现 A 则必须保证数据可用性，不管任何时候都可以向从数据查询数据，则不会响应超时或返回错误信息。通过分析发现在满足P的前提下 C 和 A 存在矛盾性。

2.1 AP

放弃一致性，追求分区容忍性和可用性。这是很多分布式系统设计时的选择。

例如：上边的商品管理，完全可以实现 AP，前提是只要用户可以接受所查询到的数据在一定时间内不是最新的即可。

通常实现 AP 都会保证最终一致性，后面将的 BASE 理论就是根据 AP 来扩展的，一些业务场景比如：订单退款，今日退款成功，明日账户到账，只要用户可以接受在一定的时间内到账即可。

2.2 CP

放弃可用性，追求一致性和分区容错性，zookeeper 其实就是追求的强一致，又比如跨行转账，一次转账请求要等待双方银行系统都完成整个事务才算完成。

2.3 CA

放弃分区容忍性，即不进行分区，不考虑由于网络不通或结点挂掉的问题，则可以实现一致性和可用性。那么系统将不是一个标准的分布式系统，最常用的关系型数据就满足了 CA。上边的商品管理，如果要实现 CA 则架构如下：

主数据库和从数据库中间不在进行数据同步，数据库可以响应每次的查询请求，通过事务隔离级别实现每个查询请求都可以返回最新的数据。

3 BASE理论

3.1 强一致性和最终一致性

CAP 理论告诉我们一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容忍性（Partition tolerance）这三项中的两项，其中AP在实际应用中较多，AP 即舍弃一致性，保证可用性和分区容忍性，但是在实际生产中很多场景都要实现一致性，比如前边我们举的例子主数据库向从数据库同步数据，即使不要一致性，但是最终也要将数据同步成功来保证数据一致，这种一致性和 CAP 中的一致性不同，CAP 中的一致性要求在任何时间查询每个结点数据都必须一致，它强调的是强一致性，但是最终一致性是允许可以在一段时间内每个结点的数据不一致，但是经过一段时间每个结点的数据必须一致，它强调的是最终数据的一致性。

3.2 BASE理论介绍

BASE 是 Basically Available（基本可用） 、**Soft state（软状态）**和 **Eventually consistent （最终一致性）**三个短语的缩写。BASE 理论是对 CAP 中 AP 的一个扩展，通过牺牲强一致性来获得可用性，当出现故障允许部分不可用但要保证核心功能可用，允许数据在一段时间内是不一致的，但最终达到一致状态。满足BASE理论的事务，我们称之为"柔性事务"。

3.2.1 基本可用

分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用。如电商网站交易付款出现问题了，商品依然可以正常浏览。

3.2.2 软状态

由于不要求强一致性，所以BASE允许系统中存在中间状态（也叫软状态），这个状态不影响系统可用性，如订单的"支付中"、"数据同步中"等状态，待数据最终一致后状态改为"成功"状态。

3.3.3 最终一致

最终一致是指经过一段时间后，所有节点数据都将会达到一致。如订单的"支付中"状态，最终会变为"支付成功"或者"支付失败"，使订单状态与实际交易结果达成一致，但需要一定时间的延迟、等待。