从 ACID 到 CAP/BASE

骑猪看日落 2023-01-17 06:26 99阅读 0赞

# ACID #

事务 （Transaction） 是由一系列对系统中数据进行访问与更新的操作所组成的一个程序 执行逻辑单元（Unit）, 狭义上的事务特指数据库事务。一方面，当多个应用程序并发访 问数据库时，事务可以在这些应用程序之间提供一个隔离方法，以防止彼此的操作互相 干扰。另一方面，事务为数据库操作序列提了一个从失败中恢复到正常状态的方法， 同时提供了数据库即使在异常状态下仍能保持数据一致性的方法。 事务具有四个特征，分别是原子性( Atomicity) 、一致性( Consistency) 、隔离性 (Isolation) 和持久性(Durability), 简称为事务的 ACID 特性。

**原子性**  
事务的原子性是指事务必须是一个原子的操作序列单元。事务中包含的各项操作在一次 执行过程中，只允许出现以下两种状态之一

*  全部成功执行。
 *  全部不执行。

任何一项操作失败都将导致整个事务失败，同时其他已经被执行的操作都将被撤销并回 滚，只有所有的操作全部成功，整个事务才算是成功完成。

**一致性**  
事务的一致性是指事务的执行不能破坏数据库数据的完整性和一致性，一个事务在执行 之前和执行之后，数据库都必须处于一致性状态。也就是说，事务执行的结果必须是使 数据库从一个一致性状态转变到另一个一致性状态，因此当数据库只包含成功事务提交 的结果时，就能说数据库处于一致性状态。而如果数据库系统在运行过程中发生故障， 有些事务尚未完成就被迫中断，这些未完成的事务对数据库所做的修改有一部分已写入 物理数据库，这时数据库就处于一种不正确的状态，或者说是不一致的状态。

**隔离性**  
事务的隔离性是指在并发环境中，并发的事务是相互隔离的，一个事务的执行不能被其 他事务干扰。也就是说，不同的事务并发操纵相同的数据时，每个事务都有各自完整的 数据空间，即一个事务内部的操作及使用的数据对其他并发事务是隔离的，并发执行的 各个事务之间不能互相干扰。

在标准 SQL 规范中，定义了 4 个事务隔离级别，不同的隔离级别对事务的处理不同， 如未授权读取、授权读取、可重复读取和串行化冲。

**持久性**  
事务的持久性也被称为永久性，是指一个事务一旦提交，它对数据库中对应数据的状态 变更就应该是永久性的。换句话说，一旦某个事务成功结束，那么它对数据库所做的更 新就必须被永久保存下来——即使发生系统崩溃或机器宕机等故障，只要数据库能够重 新启动，那么一定能够将其恢复到事务成功结束时的状态。

# 分布式事务 #

分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位 于分布式系统的不同节点之上。通常一个分布式事务中会涉及对多个数据源或业务系统 的操作。

我们可以设想一个最典型的分布式事务场景：一个跨银行的转账操作涉及调用两个异地 的银行服务，其中一个是本地银行提供的取款服务，另一个则是目标银行提供的存款服 务，这两个服务本身是无状态并且是互相独立的，共同构成了一个完整的分布式事务。 如果从本地银行取款成功，但是因为某种原因存款服务失败了，那么就必须回滚到取款 前的状态，否则用户可能会发现自己的钱不翼而飞了。

从上面这个例子中，我们可以看到，一个分布式事务可以看作是由多个分布式的操作序列组成的，例如上面例子中的取款服务和存款服务，通常可以把这一系列分布式的操作序列称为子事务。因此，分布式事务也可以被定义为一种嵌套型的事务，同时也就具有 ACID 事务特性。但由于在分布式事务中，各个子事务的执行是分布式的，因此要实 现一种能够保证 ACID 特性的分布式事务处理系统就显得格外复杂。

## CAP 定理 ##

CAP 理论告诉我们，一个，分布式系统不可能同时满足一致性 （C： Consistency）, 可用性 （A： Availability）和分区容错性 （P： Partition tolerance） 这三个基本需求，最多只能同 时满足其中的两项。

**一致性**  
在分布式环境中，一致性是指数据在多个副本之间是否能够保持一致的特性。在一致性 的需求下，当一个系统在数据一致的状态下执行更新操作后，应该保证系统的数据仍然 处于一致的状态。对于一个将数据副本分布在不同分布式节点上的系统来说，如果对第一个节点的数据进 行了更新操作并且更新成功后，却没有使得第二个节点上的数据得到相应的更新，于是 在对第二个节点的数据进行读取操作时，获取的依然是老数据（或称为脏数据），这就 是典型的分布式数据不一致情况。在分布式系统中，如果能够做到针对一个数据项的更 新操作执行成功后，所有的用户都可以读取到其最新的值，那么这样的系统就被认为具有强一致性（或严格的一致性）。

**可用性**  
可用性是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是 能够在有限的时间内返回结果。这里我们重点看下“有限的时间内”和“返回结果二“有限的时间内”是指，对于用户的一个操作请求，系统必须能够在指定的时间（即 响应时间）内返回对应的处理结果，如果超过了这个时间范围，那么系统就被认为正常的响应结果。正常的响应结果通常能够明确地映出对请求的处理结 果，即成功或失败，而不是一个让用户感到困惑的返回结果。

**分区容错性**  
分区容错性约束了一个分布式系统需要具有如下特性：分布式系统在遇到任何网络分区 故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络 环境都发生了故障。

网络分区是指在分布式系统中，不同的节点分布在不同的子网络（机房或异地网络等） 中，由于一些特殊的原因导致这些子网络之间出现网络不连通的状况，但各个子网络的 内部网络是正常的，从而导致整个系统的网络环境被切分成了若干个孤立的区域。需要 注意的是，组成一个分布式系统的每个节点的加入与退出都可以看作是一个特殊的网络分区。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70]

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 1]

从 CAP 定理中我们可以看出，一个分布式系统不可能同时满足一致性、可用性和分区 容错性这三个需求。

另一方面，需要明确的一点是，对于一个分布式系统而言，分区容错性可以说是一个最基本的要求。为什么这样说，其实很简单，因为既然是一个分布式 系统，那么分布式系统中的组件必然需要被部署到不同的节点，否则也就无所谓分布式系统了，因此必然出现子网络。而对于分布式系统而言，网络问题又是一个必定会出现 的异常情况，因此分区容错性也就成为了一个分布式系统必然需要面对和解决的问题。 因此系统架构设计师往往需要把精力花在如何根据业务特点在 C （一致性）和 A （可用 性）之间寻求平衡。

# BASE 理论 #

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

BASE 是对 CAP 中一致性和可用性权衡的结 果，其来源于对大规模互联网系统分布式实践的总结，是基于 CAP 定理逐步演化而来 的，其核心思想是即使无法做到强一致性 (Strong consistency), 但每个应用都可以根据 自身的业务特点，采用适当的方式来使系统达到最终一•致性 (Eventual consistency), 接下 来我们着重对 BASE 中的三要素进行详细讲解。

**基本可用**  
基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性一。

但请注 意，这绝不等价于系统不可用。以下两个就是“基本可用”的典型例子。

*  响应时间上的损失：正常情况下，一个在线搜索引擎需要在 0.5 秒之内返回给用户 相应的查询结果，但由于出现故障(比如系统部分机房发生断电或断网故障)，查 询结果的响应时间增加到了 1 ~2 秒。
 *  功能上的损失：正常情况下，在一个电子商务网站上进行购物，消费者几乎能够 顺利地完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购 物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级 页面。

**弱状态**  
弱状态也称为软状态，和硬状态相对，是指允许系统中的数据存在中间状态，并认为该 中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进 行数据同步的过程存在延时。

**最终一致性**  
最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到 一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而 不需要实时保证系统数据的强一致性。

一致性大的来看，其实有两种，一种是主从数据的一致性，一种是多个对等数据节点间的一致性

*  主从数据的一致性，多数由于异步复制导致
 *  对等数据节点的一致性，多数也是由于异步处理导致，比如下单流程中，生成订单后，将扣减库存操作扔到 mq，然后异步扣减库存，此时系统的数据就会存在短暂的不一致性；其弱状态是通过缓存来保证的。

# 小结 #

总的来说， BASE 理论面向的是大型高可用可扩展的分布式系统，和传统事务的 ACID 特性是相反的，它完全不同于 ACID 的强一致性模型，而是提出通过牺牲强一致性来获 得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。但同时，在实 际的分布式场景中，不同业务单元和组件对数据一致性的要求是不同的，因此在具体的 分布式系统架构设计过程中， ACID 特性与 BASE 理论往往又会结合在一起使用。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70]: /images/20221021/bc84bbaa285e46aa97da61f6abd989cf.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNDYwNw_size_16_color_FFFFFF_t_70 1]: /images/20221021/8d28dd3a38634694941aeec4d2259dd4.png