分布式事务 |
AI工具、AI绘图、AI专栏
如果你想学到最前沿、最火爆的技术,赶快加入吧✨
作者简介:硕风和炜,CSDN-Java领域优质创作者,保研|国家奖学金|JAVA开发技术栈|面试刷题|面经八股文|经验分享|好用的网站工具分享
恭喜你发现一枚宝藏博主,赶快收入囊中吧
人生如棋,我愿为卒,行动虽慢,可谁曾见我后退一步?
分布式事务 |
X/Open DTP(Distributed Transaction Process)是一个分布式事务模型。这个模型主要使用了两段提交(2PC - Two-Phase-Commit)来保证分布式事务的完整性。
1994 年,X/Open 组织(即现在的 Open Group )定义了分布式事务处理的DTP 模型。该模型包括这样几个角色:
在该模型中,一个分布式事务(全局事务)可以被拆分成许多个本地事务,运行在不同的AP和RM上。每个本地事务的ACID很好实现,但是全局事务必须保证其中包含的每一个本地事务都能同时成功,若有一个本地事务失败,则所有其它事务都必须回滚。但问题是,本地事务处理过程中,并不知道其它事务的运行状态。因此,就需要通过CRM来通知各个本地事务,同步事务执行的状态。
因此,各个本地事务的通信必须有统一的标准,否则不同数据库间就无法通信。XA就是 X/Open DTP中通信中间件与TM间联系的接口规范,定义了用于通知事务开始、提交、终止、回滚等接口,各个数据库厂商都必须实现这些接口。
XA是由X/Open组织提出的分布式事务的规范,是基于两阶段提交协议。XA 规范主要定义了事务管理器(Transaction Manager)和局部资源管理器(Local Resource Manager)之间的接口。目前主流的关系型数据库产品都是实现了XA接口。
XA之所以需要引入事务管理器,是因为在分布式系统中,从理论上讲两台机器理论上无法达到一致的状态,需要引入一个单点进行协调。由全局事务管理器管理和协调的事务,可以跨越多个资源(数据库)和进程。
事务管理器用来保证所有的事务参与者都完成了第一阶段的准备工作。第二阶段:如果事务管理器收到所有参与者都准备好的消息,就会通知所有的事务都可以提交了。MySQL 在这个XA事务中扮演的是参与者的角色,而不是事务管理器。
二阶提交协议就是根据这一思想衍生出来的,将全局事务拆分为两个阶段来执行:
这个过程中需要一个协调者(coordinator),还有事务的参与者(voter)。
投票阶段:协调组询问各个事务参与者,是否可以执行事务。每个事务参与者执行事务,写入redo和undo日志,然后反馈事务执行成功的信息(agree
)
提交阶段:协调组发现每个参与者都可以执行事务(agree
),于是向各个事务参与者发出commit
指令,各个事务参与者提交事务。
投票阶段:协调组询问各个事务参与者,是否可以执行事务。每个事务参与者执行事务,写入redo和undo日志,然后反馈事务执行结果,但只要有一个参与者返回的是Disagree
,则说明执行失败。
提交阶段:协调组发现有一个或多个参与者返回的是Disagree
,认为执行失败。于是向各个事务参与者发出abort
指令,各个事务参与者回滚事务。
全流程的同步阻塞:不管是第一阶段还是第二阶段,所有参与节点都是事务阻塞型。当参与者占有公共资源时,其他第三方访问公共资源可能不得不处于阻塞状态。
TM单点故障:由于全流程依赖TM的协调,一旦TM发生故障。参与者会一直阻塞下去。尤其在第二阶段,TM发生故障,那么所有的参与者还都处于锁定事务资源的状态中,而无法继续完成事务操作。所有参与者必须等待TM重新上线(TM重新选举)后才能继续工作。
TM脑裂引起数据不一致:在第二阶段中,当TM向参与者发送commit请求之后,发生了局部网络异常或者在发送commit请求过程中TM发生了故障,这会导致只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据不一致性的现象。
TM脑裂引起事务状态不确定:TM再发出commit消息之后宕机,而接收到这条消息的参与者同时也宕机了。那么即使通过选举协议产生了新的TM,这条事务的状态也是不确定的,没人知道事务是否被已经提交。
第一阶段: CanCommit阶段:
TM协调者向所有参与者发送消息,然后各个库返回结果,不会执行实际的SQL语句,就是验证各个库网络的环境,是否准备成功,如果事务的准备工作成功,则回应“可以提交”,否则回应“拒绝提交”,需要注意的这个阶段存在超时的中止机制。
第二阶段: PreCommit阶段:
注意:此时会执行SQL语句,但是依然不会提交,还是会继续确定一遍!
第三阶段: DoCommit阶段
整理流程如下图所示:该图片来自来于互联网
TCC(Try-Confirm-Cancel)的概念,最早是由 Pat Helland 于 2007 年发表的一篇名为《Life beyond Distributed Transactions:an Apostate’s Opinion》的论文提出。
TCC 是服务化的两阶段编程模型,其 Try、Confirm、Cancel 3 个方法均由业务编码实现:
TCC的基本原理
它本质是一种补偿的思路。事务运行过程包括三个方法,
执行分两个阶段:
try、confirm、cancel都是独立的事务,不受其它参与者的影响,不会阻塞等待它人
try、confirm、cancel由程序员在业务层编写,锁粒度有代码控制
以之前的下单业务中的扣减余额为例来看下三个不同的方法要怎么编写,假设账户A原来余额是100,需要余额扣减30元。如图:
一阶段(Try):余额检查,并冻结用户部分金额,此阶段执行完毕,事务已经提交
二阶段
优势
TCC执行的每一个阶段都会提交本地事务并释放锁,并不需要等待其它事务的执行结果。而如果其它事务执行失败,最后不是回滚,而是执行补偿操作。这样就避免了资源的长期锁定和阻塞等待,执行效率比较高,属于性能比较好的分布式事务方式。
缺点
代码侵入:需要人为编写代码实现try、confirm、cancel,代码侵入较多
开发成本高:一个业务需要拆分成3个步骤,分别编写业务实现,业务编写比较复杂
安全性考虑:cancel动作如果执行失败,资源就无法释放,需要引入重试机制,而重试可能导致重复执行,还要考虑重试时的幂等问题
对事务有一定的一致性要求(最终一致)
对性能要求较高
开发人员具备较高的编码能力和幂等处理经验,try confirm和cancel都有可能被多次调用
消息队列的方案最初是由 eBay 提出,基于TCC模式,消息中间件可以基于 Kafka、RocketMQ 等消息队列。
此方案的核心是将分布式事务拆分成本地事务进行处理,将需要分布式处理的任务通过消息日志的方式来异步执行。消息日志可以存储到本地文本、数据库或MQ中间件,再通过业务规则人工发起重试。
步骤1:事务主动方处理本地事务。事务主动方在本地事务中处理业务更新操作和MQ写消息操作。例如: A用户给B用户转账,主动方先执行扣款操作
步骤 2:事务发起者A通过MQ将需要执行的事务信息发送给事务参与者B。事务主动方主动写消息到MQ,事务消费方接收并处理MQ中的消息。
步骤 3:事务被动方通过MQ中间件,通知事务主动方事务已处理的消息,事务主动方根据反馈结果提交或回滚事务。例如: 订单生成成功,通知主动方法,主动放即可以提交.
为了数据的一致性,当流程中遇到错误需要重试,容错处理规则如下:
当步骤 1 处理出错,事务回滚,相当于什么都没发生。
当步骤 2 处理出错,由于未处理的事务消息还是保存在事务发送方,可以重试或撤销本地业务操作。
如果事务被动方消费消息异常,需要不断重试,业务处理逻辑需要保证幂等。
如果是事务被动方业务上的处理失败,可以通过MQ通知事务主动方进行补偿或者事务回滚。
那么问题来了,我们如何保证消息发送一定成功?如何保证消费者一定能收到消息?
为了避免消息发送失败或丢失,我们可以把消息持久化到数据库中。实现时有简化版本和解耦合版本两种方式。
事务发起者:
事务接收者:
额外的定时任务
总结上面的几种模型,消息事务的优缺点如下:
2019年 1 月份,Seata 开源了 AT 模式。AT 模式是一种无侵入的分布式事务解决方案。可以看做是对TCC或者二阶段提交模型的一种优化,解决了TCC模式中的代码侵入、编码复杂等问题。
在 AT 模式下,用户只需关注自己的“业务 SQL”,用户的 “业务 SQL” 作为一阶段,Seata 框架会自动生成事务的二阶段提交和回滚操作。
Seata官方文档。
有没有感觉跟TCC的执行很像,都是分两个阶段:
但AT模式底层做的事情可完全不同,而且第二阶段根本不需要我们编写,全部有Seata自己实现了。也就是说:我们写的代码与本地事务时代码一样,无需手动处理分布式事务。
那么,AT模式如何实现无代码侵入,如何帮我们自动实现二阶段代码的呢?
一阶段
在一阶段,Seata 会拦截“业务 SQL”,首先解析 SQL 语义,找到“业务 SQL
”要更新的业务数据,在业务数据被更新前,将其保存成“before image
”,然后执行“业务 SQL
”更新业务数据,在业务数据更新之后,再将其保存成“after image
”,最后获取全局行锁,提交事务。以上操作全部在一个数据库事务内完成,这样保证了一阶段操作的原子性。
这里的before image
和after image
类似于数据库的undo和redo日志,但其实是用数据库模拟的。
update t_stock set stock = stock - 2 where id = 1
select * from t_stock where id = 1 ,保存元快照 before image ,类似undo日志.
放行执行真实SQL,执行完成,再次查询,获取到最新的库存数据,再将数据保存到镜像after image 类似redo.
提交业务如果成功,就清楚快照信息,失败,则根据redo 中的数据与数据库的数据进行对比,如果一直就回滚,如果不一致 出现脏数据,就需要人工介入.
AT模式最重要的一点就是 程序员只需要关注业务处理的本身即可,不需要考虑回滚补偿等问题.代码写的跟以前一模一杨.
二阶段提交
业务 SQL
”在一阶段已经提交至数据库, 所以 Seata 框架只需将一阶段保存的快照数据和行锁删掉,完成数据清理即可。二阶段回滚
业务 SQL
”,还原业务数据。回滚方式便是用“before image
”还原业务数据;但在还原前要首先要校验脏写,对比“数据库当前业务数据”和 “after image
”,如果两份数据完全一致就说明没有脏写,可以还原业务数据,如果不一致就说明有脏写
,出现脏写就需要转人工处理。不过因为有全局锁机制,所以可以降低出现脏写
的概率。
AT 模式的一阶段、二阶段提交和回滚均由 Seata 框架自动生成,用户只需编写“业务 SQL”,便能轻松接入分布式事务,AT 模式是一种对业务无任何侵入的分布式事务解决方案。
优点:
缺点:
Saga 模式是 Seata 即将开源的长事务解决方案,将由蚂蚁金服主要贡献。其理论基础是Hector & Kenneth 在1987年发表的论文Sagas。
Seata官网对于Saga学习知道
在分布式事务场景下,我们把一个Saga分布式事务看做是一个由多个本地事务组成的事务,每个本地事务都有一个与之对应的补偿事务。在Saga事务的执行过程中,如果某一步执行出现异常,Saga事务会被终止,同时会调用对应的补偿事务完成相关的恢复操作,这样保证Saga相关的本地事务要么都是执行成功,要么通过补偿恢复成为事务执行之前的状态。(自动反向补偿机制)。
每个 Ti 都有对应的幂等补偿动作 Ci,补偿动作用于撤销 Ti 造成的结果。
Saga是一种补偿模式,它定义了两种补偿策略:
优点
缺点
本篇文章主要内容分布式事务七种模式理论详解方案,主要有XA协议,2PC,3PC,TCC,消息队列,AT,Saga。更多内容支持创作中,大家敬请期待呦!!
最后,我想和大家分享一句一直激励我的座右铭,希望可以与大家共勉! |