分布式事务的一些基础知识和几种经典解决方案的对比

咦940

已于 2023-10-23 11:39:07 修改

阅读量821

点赞数 1

分类专栏：分布式系统文章标签：分布式数据库

于 2020-12-14 11:03:19 首次发布

本文链接：https://blog.csdn.net/qq_35939417/article/details/109516867

版权

分布式系统专栏收录该内容

4 篇文章 0 订阅

订阅专栏

分布式事务的一些基础知识和几种经典解决方案的对比

应用场景
DTP模型与XA规范
经典的分布式系统理论
- CAP
- BASE
柔性事务
参考资料

应用场景

微服务架构下数据库的拆分，完成某一个业务可能需要横跨多个服务，操作多个数据库，这就涉及到了分布式事务。需要操作的资源位于多个资源服务器上，而应用需要保证对于多个资源服务器的数据的操作，要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同资源服务器的数据一致性。

跨库事务

跨库事务指的是，一个应用某个功能需要操作多个库，不同的库中存储不同的业务数据。下图演示了一个服务同时操作两个数据库的情况：
在这里插入图片描述

服务化（SOA）

在微服务架构下，一个业务可能涉及到多个服务，每个服务都有自己的数据库。下图演示了一个3个服务之间彼此调用的架构：
在这里插入图片描述
Service A完成某个业务需要直接操作数据库，同时需要调用Service B和Service C，而Service B又同时操作了2个数据库，Service C也操作了一个库，需要保证这些跨服务的对多个数据库的操作的原子性，实际上这可能是最典型的分布式事务场景。

小结

上述讨论的分布式事务场景中，无一例外的都直接或者间接的操作了多个数据库。如何保证事务的ACID特性，对于分布式事务实现方案而言，是非常大的挑战。同时，分布式事务实现方案还必须要考虑性能的问题，如果为了严格保证ACID特性，导致性能严重下降，那么对于一些要求快速响应的业务，是无法接受的。

DTP模型与XA规范

DTP模型

DTP模型（Distributed Transaction Processing:Reference Model）是一种全局事务模型，全局事务模型中事务由事务管理器全局管理。全局事务的提交一般使用两阶段提交协议。构成DTP模型的有5个基本元素：

资源管理器（Resource Manager,简称RM）：提供访问资源的方法。如数据库、文件系统等。

事务管理器（Transaction Manager,简称TM）：协调全局事务中的各个事务，需要和全局事务的所有资源管理器进行通信。具体职责包括分配事务唯一标识、监控事务的执行速度、负责事务的提交与回滚等。

应用程序（Application Program,简称AP）：定义事务的边界（即定义事务的开始和结束），并在事务边界内对资源进行操作。

通信资源管理器（Communication Resource Manager,简称CRM）：控制一个TM域（TM domain）内或者跨TM域的分布式应用之间的通信。

通信协议（Communication Protocol,简称CP）：提供CRM提供的分布式应用节点之间的底层通信服务。

一个DTP模型实例至少有3个组成部分：应用程序、资源管理器、事务管理器。如下图所示：

在这里插入图片描述
上面这张图类似于前面提到的跨库事务的概念，即单个应用需要操作多个数据库。在这里就是一个AP需要操作多个RM上的资源。AP通过TM来声明一个全局事务，然后操作不同RM上的资源，最后通知TM提交或者回滚全局事务。

如果分布式事务需要跨多个应用，类似于前面提到的服务化（SOA）场景，那么每个模型实例中，还需要额外的加入一个通信资源管理器CRM，这时就变成了跨域的全局事务，如下图所示：

在这里插入图片描述
CRM作为多个模型之间通信的桥梁，主要作用如下：

基本的通信能力：从这个角度看，可以将CRM类比为RPC框架，模型实例之间通过RPC调用实现彼此的通信。
事务传播能力：与传统RPC框架不同的是，CRM底层采用OSI TP（Open System Interconnection - Distributed Transaction Processing）通信服务，因此CRM具备事务传播能力。

XA规范

由Tuxedo首先提出的，并交给X/Open组织，作为资源管理器与事务管理器的接口标准。一些人可能误认为两阶段提交协议是在XA规范中提出来的。事实上：两阶段协议是在OSI TP标准中提出的；在DTP参考模型（《Distributed Transaction Processing:Reference Model》）中，指定了全局事务的提交要使用two-phase commit协议；而XA规范（《Distributed Transaction Processing:The XA Specification》）只是定义了两阶段提交协议中需要使用到的接口。XA规范除了定义RM-TM交互的接口（XA Interface）之外，还对两阶段协议进行了优化。XA规范中定义的RM和TM交互的接口如下图所示：

在这里插入图片描述

全局事务的提交

上述全局事务的提交使用两阶段提交协议，两阶段提交协议中的协调者对应全局事务中的事务管理器（TM），参与者对应全局事务中的资源管理器（RM）。

两阶段提交

两阶段提交（Two-Phase Commit,简称2PC），是计算机网络尤其是在数据库领域内，为了使基于分布式系统架构下的所有节点在进行事务处理过程中能够保持原子性和一致性而设计的一种协议。

在这里插入图片描述

流程

阶段一：Prepare

事务询问
协调者向所有的参与者发送事务内容，询问是否可以执行事务提交操作，并开始等待各参与者的响应
执行事务
各参与者节点执行事务操作，并记录事务日志（比如Undo Log和Redo Log）。
各参与者向协调者反馈事务询问的响应
如果参与者成功执行了事务操作，那么就反馈给协调者Ok响应，表示事务可以执行；如果参与者没有成功执行事务，那么就反馈给协调者No响应，表示事务不可以执行

阶段二：Commit
在阶段二中，协调者会根据各参与者的反馈情况来决定最终是否可以进行事务提交操作，通常包含以下两种情况：

情况一：执行事务提交
假如协调者从所有的参与者获得的反馈都是Ok响应，那么就会执行事务提交。

发送提交请求
协调者向所有参与者节点发出Commit请求
事务提交
参与者接收到Commit请求后，会正式执行事务提交操作，并在完成提交之后释放在整个事务执行期间占用的事务资源
反馈事务提交结果
参与者在完成事务提交之后，向协调者发送Ack消息
完成事务
协调者接收到所有参与者反馈的Ack消息后，完成事务

情况二：中断事务
假如任何一个参与者向协调者反馈了No响应，或者在等待超时之后，协调者尚无法接收到所有参与者的反馈响应，那么就会中断事务。

发送回滚操作
协调者向所有参与者节点发出Rollback请求
事务回滚
参与者接收到Rollback请求后，会利用其在阶段一中记录的事务日志来执行事务回滚操作，并在完成回滚之后释放在整个事务执行期间占用的资源
反馈事务回滚结果
参与者在完成事务回滚之后，向协调者发送Ack消息
中断事务
协调者接收到所有参与者反馈的Ack消息后，完成事务中断

在这里插入图片描述

优缺点

优点：原理简单、实现方便
缺点：同步阻塞、单点问题、数据不一致

下面来依次讨论这些缺点：

同步阻塞：2PC最大的问题就是同步阻塞，这会极大地限制分布式系统的性能。就拿MySQL来说，在第一阶段，数据库收到prepare请求后会锁定相关数据行，直到第二阶段完成才会释放锁。而第二阶段请求的发出又取决于TM是否收到所有数据库（RM）的回应。

单点问题：TM（协调者）的角色在整个2PC中起到了非常重要的作用，一旦TM出现问题，那么整个2PC的流程将无法运转，更为严重的是，如果协调者是在阶段一完成后还没进入阶段二时出现问题的话，那么RM（参与者）将会一直处于锁定事务资源的状态中（如果协调者采用主备或集群模式，可以重新选举一个协调者，但这里要解决因为协调者宕机导致的参与者处于阻塞状态的问题，又要先解决协调者的数据一致性问题）。

数据不一致：在2PC的阶段二中，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，这会导致只有一部分参与者接收到了commit请求，于是整个分布式系统便出现了数据不一致的现象。

三阶段提交

流程

由于两阶段提交存在的一些问题，因此研究者在两阶段提交协议的基础上进行了改造，提出了三阶段提交协议。
在这里插入图片描述
阶段一：CanCommit

事务询问
协调者向所有的参与者发送一个包含事务内容的canCommit请求，询问是否可以执行事务提交操作，并开始等待参与者的响应。
各参与者向协调者反馈事务询问的响应
参与者在接收到来自协调者的canCommit请求后，正常情况下，如果其自身认为可以顺利执行事务，那么会反馈Yes响应，并进入预备状态，否则反馈No响应。

阶段二：PreCommit
在阶段二中，协调者会根据各参与者的反馈情况来决定是否可以进行事务的PreCommit操作，通常包含两种情况。

情况一：执行事务预提交
假如协调者从所有的参与者获得的反馈都是Yes响应，那么就会执行事务预提交

发送预提交请求
协调者向所有参与者节点发出preCommit的请求，并进入prepare阶段。
事务预提交
参与者接收到preCommit请求后，会执行事务操作，并将记录日志（例如MySQL的Undo Log和Redo Logo）。
各参与者向协调者反馈事务执行的响应
如果参与者成功执行了事务操作，那么就会反馈给协调者ACk响应，同时等待最终命令——提交（commit）或终止（abort）。

发送中断请求
协调者向所有参与者节点发出abort请求。
中断事务
无论是收到来自协调者的abort请求，还是在等待协调者请求过程中出现超时，参与者都会中断事务。

阶段三：DoCommit
该阶段将进行真正的事务提交，会存在以下两种可能的情况。

情况一：执行提交

发送提交请求
进入这一阶段，假设协调者处于正常工作状态，并且它收到了来自所有参与者的Ack响应，那么它将从“预提交”状态转换到“提交”状态，并向所有的参与者发送doCommit请求。
事务提交
参与者接收到doCommit请求后，会正式执行事务提交操作，并在完成提交之后释放在整个事务执行期间占用的事务资源。
反馈事务提交结果
参与者在完成事务提交之后，向协调者发送Ack消息。
完成事务
协调者接收到所有参与者反馈的Ack消息后，完成事务。

情况二：中断事务
进入这一阶段，假如协调者处于正常工作状态，并且有任意一个参与者向协调者反馈了No响应，或者在等待超时之后，协调者尚无法接收到所有参与者的反馈响应，那么就会中断事务。

发送中断请求
协调者向所有参与者节点发送abort请求。
事务回滚
参与者接收到abort请求后，会利用其在阶段二中记录的日志信息来执行事务回滚操作，并在完成回滚之后释放整个事务执行期间占用的资源。
反馈事务回滚结果
参与者在完成事务回滚之后，向协调者发送Ack消息。
中断事务
协调者接收到所有参与者反馈的Ack消息后，中断事务。

需要注意的是，一旦进入阶段三，可能会存在以下两种故障：

协调者出现问题
协调者和参与者之间的网络出现故障

无论出现哪种故障，最终都会导致参与者无法及时接收来自协调者的doCommit或者abort请求，针对这样的异常情况，参与者都会在等待超时之后，继续进行事务提交。

优缺点

优点：相较于2PC，3PC最大的优点就是降低了参与者的阻塞范围，并且能够在出现单点故障后继续达成一致。
缺点：3PC在去除阻塞的同时也引入了新问题，那就是在参与者接收到preCommit请求后，如果网络出现分区，此时协调者所在的节点和参与者无法进行正常的网络通信，在这种情况下，该参与者依然会进行事务的提交，会导致数据不一致。

经典的分布式系统理论

CAP

一个分布式系统不可能同时满足一致性（C:Consistency）、可用性（A:Availability）和分区容错性（P:Partition tolerance）这三个基本需求，最多只能同时满足其中的两项。
在这里插入图片描述
一致性：在分布式环境中，一致性是指数据在多个副本之间是否能够保持一致的特性。在一致性的需求下，当一个系统在数据一致的状态下执行更新操作后，应该保证系统的数据仍然处于一致的状态。关于一致性，如果的确能像上面描述的那样时刻保证客户端看到的数据都是一致的，那么称之为强一致性；如果允许存在中间状态，只要求经过一段时间后，数据最终是一致的，则称之为最终一致性；此外，如果允许存在部分数据不一致，那么就称之为弱一致性。

可用性：可用性是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。“有限的时间内”是指，对于用户的一个操作请求，系统必须能够在指定的时间内返回对应的处理结果，如果超过了这个时间范围，那么系统就被认为是不可用的。另外，“有限的时间内”是一个在系统设计之初就设定好的系统运行指标。“返回结果”是可用性的另一个非常重要的指标，它要求系统在完成对用户请求的处理后，返回一个正常的响应结果，不论这个结果是成功还是失败。

分区容错性：分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性或可用性的服务，除非是整个网络环境都发生了故障。网络分区是指在分布式系统中，不同的节点分布在不同的子网络（机房或异地网络）中，由于一些特殊的原因导致这些子网络之间出现网络不连通的情况，但各个子网络的内部网络是正常的，从而导致整个系统的网络环境被切分成了若干个孤立的区域。

在这里插入图片描述

BASE

BASE是Basically Available(基本可用)、Soft state(软状态)和Eventually consistent(最终一致性)三个短语的简称。它是对CAP理论的延伸，核心思想是即使无法做到强一致性（Strong Consistency, CAP的一致性就是强一致性），但应用可以采用合适的方式达到最终一致性（Eventually Consistency）。

基本可用：是指分布式系统在出现不可预知故障的时候，允许损失部分可用性——但请注意，这绝不等价于系统不可用。以下两个就是“基本可用”的典型例子：

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

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

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

柔性事务

TCC

概述

TCC是Try、Confirm、Cancel的合称。

Try：检查及预留业务资源。

完成所有业务检查（一致性）
预留必须业务资源（准隔离性）

Confirm：执行业务操作

不做任何业务检查
只使用Try阶段预留的业务资源
满足幂等性

Cancel：取消执行业务操作

释放Try阶段预留的业务资源
满足幂等性

TCC是一种补偿型事务。补偿是一个独立的支持ACID特性的本地事务，用于在逻辑上取消服务提供者上一个ACID事务造成的影响，对于一个长事务，与其实现一个巨大的分布式ACID事务，不如使用基于补偿的方案，把每一次服务调用当做一个较短的本地ACID事务来处理，执行完就立即提交。TCC中confirm和cancel就是对try阶段的补偿，用于取消try阶段本地事务造成的影响。