谈谈分布式事务的CAP和BASE理论

看点有用的 2021-10-27

416

点击上方蓝字关注我们

前言

随着互联化的发展，各种项目逐渐向分布式服务转换。在单机数据库中，我们很容易能够实现一套满足ACID特性的事务处理系统，但是在分布式数据库中，数据分散在各台不同的机器上，如何对这些数据进行分布式事务处理具有非常大的挑战。

什么是分布式事务

对于传统应用的事务原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）我们都已经很清楚，这里就不再介绍。

CAP和BASE理论

介绍分布式事务的时候有两个理论肯定是绕不开的，那就是CAP和BASE理论。

CAP

C：一致性（Consistence），所有节点访问的都是同一份最新的数据副本。

A：可用性（Availability），每次请求都能获取正确的响应，但不保证获取的数据为最新数据。

P：分区容错性（Tolerance of network Partition），以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区情况，当前操作必须在C和A之间做出选择。

A和C容易理解，P的含义进一步从“分区”和“容错”的角度来理解。一个分布式系统中由若干节点组成，每个节点间通过网络进行通信。当有些节点之间因为网络原因不能继续通信时，就会形成多个孤立的节点，称为“网络分区”。容错是一种分布式能力，我们要做到节点之间的网络异常发生后整个分布式系统仍然是可用的。如果数据只存储在一个节点上，那么当“网络分区”现象出现后，与这个节点失去通信能力的所有节点都访问不到数据了。为了提高分布式系统的容错能力，会把数据复制到分布式系统的所有节点上面，当分区再次出现后，每个节点上面的请求都能够访问到数据，保证了可用性，即通过提高分区容错性来保证分布式系统可用性。

当然，这也带来了一致性的问题，复制的数据节点越多，节点上数据不一致性的可能性就越大，因为网络总是一个不确定的因素。

CAP为什么不能同时满足

接触CAP理论的时候先入为主的被告知三种因素不可能同时被满足，一个分布式系统既然不能同时满足上述的三个需求，因此在进行对cap定理的应用时，我们就需要去抛弃一项（如下图）。为什么不能同时满足呢？下面就来进行说明。

下图中有N1和N2两个节点，各自节点内分别有一个web应用A和web应用B，还有数据库V，V是数据存储的两个子数据库。这样就构成了基本的分布式系统。

下图是一个分布式系统下正常运行的示意图。用户发送写请求到N1，应用A将数据V0更新为V1.分布式系统进行数据复制操作M，将N2中的V0更新为V1。这样N1和N2中的数据都为V1，当新用户请求到N2的时候，数据一致。

如何理解CAP不能同时满足呢？我们先“按住”一端，看另外两个端是否都能参与进来。比如分布式系统首先要具备分区容错性P，不然分布式的意义就不大了。我们已经了解到，一个分布式系统最大的不确定性因素就是网络。N1和N2之间的网络通信突然出现故障，为了支持这种网络异常，必须要满足分区容错性。那么一致性和可用性是否可以同时满足呢？

如下图所示，用户发送写请求到N1，应用A将数据V0更新为V1，由于N1和N2之间发生了网络通信故障，那么分布式系统进行数据复制M操作的时候失败，N2中的数据一直是V0。此时用户发送读请求到N2，由于数据复制失败，N2返回的是老数据V0.这个时候有两种选择，一是牺牲数据一致性，返回给用户旧数据V0；二是牺牲可用性，让用户等待，直到网络通信恢复正常，数据赋值操作M完成之后，返回给用户新数据V1。

这个过程证明分布式系统在满足分区容错性能的前提下，，一致性和可用性只能选择一个。

CAP是分布式系统下的定理，鉴于分布式系统的网络特性，CAP不能同时满足的根本原因主要是存在网络故障。实际造成通信出现问题还有其他原因，网络是其中一个最大的不确定性因素，也可能是GC的Stop The World阻塞太久，还可能是服务器程序有一个死循环导致CPU利用率到100%从而拒绝服务。
BASE理论

追求可用性和一致性是分布式系统一直努力的方向，但始终不能完美的同时拥有这两种特性。行业的科学家们在追求美好的过程中在CAP定理的基础上演化形成了BASE理论。BASE理论是指基本可用性（Basically Available）、软状态（Soft State）和最终一致性（Eventual Consistency）。

基本可用性：分布式系统出现故障时，允许损失一部分可用性，拿响应时间和功能上的损失来换取可用。比如大促的时候访问量巨大，可以对一些不重要的功能做降级处理，同时在响应时间上做放宽限制来保证可用性。
软状态：也叫做弱状态或柔性状态，比如订单系统，在下单完成进行支付的过程中，我们可以让页面显示“支付中”，等待支付系统彻底同步完数据，订单系统才显示支付完成。允许系统存在中间状态，这个中间状态又不会影响系统整体可用性。比如，数据库读写分离，写库同步到读库会有一个延时，实际上这也是一种柔性状态。
最终一致性：在允许出现中间状态的情况下，经过一段时间之后，各项数据状态才最终达到一致，比如订单系统的订单状态，库存系统的库存状态和支付系统的支付状态。与最终一致性对应的是强一致性和弱一致性，最终一致性可以理解为特殊的弱一致性。

ACID是传统数据库常用的设计思想，它追求的是强一致性。BASE是大型分布式系统场景下的设计思想，通过牺牲强一致性获得高可用性。互联网最核心的需求是什么？高可用。

老的方式实现分布式事务是通过两段提交来实现的，分为准备阶段和提交阶段。两阶段事务的关键在准备阶段，在这个阶段所有参与者必须完成约束检查，达成与分布式事务一致性的共识。提交阶段根据之前达成的共识完成相应的操作。提交事务的过程中需要在多个资源节点之间进行协调，而且每个节点对锁资源的释放必须要等到事务最终提交的时候。所以两段事务提交会耗费更长的时间。事务执行时间长意味着对锁资源发生冲突的概率增加，当事务的并发量积累到一定数量的时候，很可能出现事务积压甚至出现死锁，系统的性能和吞吐量就会下降。

结语

在现在的电商领域里，绝大部分场景下，一般不会使用两段提交这样低效的方式来实现分布式事务。我们会采取上面支持BASE理论的方式实现分布式事务来保证系统的性能我业务数据的最终一致。

点个在看你最好看

数据库

文章转载自看点有用的，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

谈谈分布式事务的CAP和BASE理论

评论