文章目录
- 分布式事务:
- 1、一致性理论
- 2、两阶段提交(2PC)
- 3、三阶段提交(3PC)
- 4、Seata分布式事务方案
上一篇降到了 分布式锁,先来和大家聊一聊分布式事务,
分布式锁的链接如下: https://blog.csdn.net/weixin_44797327/article/details/134611193?spm=1001.2014.3001.5502
分布式事务:
1、一致性理论
分布式事务的目的是保障分库数据一致性,而跨库事务会遇到各种不可控制的问题,如个别节点永久性宕机,像单机事务一样的ACID是无法奢望的。另外,业界著名的CAP理论也告诉我们,对分布式系统,需要将数据的一致性、系统可用性、分区容忍性放在天平上一起考虑。
两阶段提交协议(简称2PC) 是实现分布式事务较为经典的方案,但2PC 的可扩展性很差,在分布式架构下应用代价较大,eBay 架构师Dan Pritchett 提出了BASE 理论,用于解决大规模分布式系统下的数据一致性问题。BASE 理论 告诉我们:可以通过放弃系统在每个时刻的强一致性来换取系统的可扩展性。
-
CAP理论
在分布式系统中,**一致性(Consistency)、可用性(Availability)和分区容忍性(Partition Tolerance)**三个要素最多只能同时满足两个,不可兼得。其中 分区容忍性 又是不可或缺的。
- 一致性:分布式环境下多个节点的数据是否强一致。
- 可用性:分布式服务能一直保证可用状态。当用户发出一个请求后,服务能在有限时间内返回结果。
- 分区容忍性:特指对网络分区的容忍性。即,系统中任意信息的丢失或失败不会影响系统的继续运作
-
BASE 理论
- 基本可用(Basically Available):指分布式系统在出现故障时,允许损失部分的可用性来保证核心可用。
- 软状态(Soft State):指允许分布式系统存在中间状态,该中间状态不会影响到系统的整体可用性。
- 最终一致性(Eventual Consistency):指分布式系统中的所有副本数据经过一定时间后,最终能够达到一致的状态。
2、两阶段提交(2PC)
二阶段提交协议(Two-phase Commit,即 2PC)是常用的分布式事务解决方案,即 将事务的提交过程分为准备阶段和提交阶段两个阶段来进行处理,通过引入协调者(Coordinator)来协调参与者的行为,并最终决定这些参与者是否要真正执行事务。
事务协调者(事务管理器):事务的发起者
事务参与者(资源管理器):事务的执行者
-
准备阶段(投票阶段)
协调者询问参与者事务是否执行成功,参与者发回事务执行结果,但该阶段并未提交事务。1)协调者向所有参与者发送事务内容,询问是否可以提交事务,并等待答复;
2)各参与者执行事务操作,将 undo 和 redo 信息记入事务日志中(但不提交事务);
3)如果参与者执行成功,给协调者反馈同意,否则反馈终止。
-
提交阶段(执行阶段)
如果事务在每个参与者上都执行成功,事务协调者发送通知让参与者提交事务;否则,协调者发送通知让参与者回滚事务。
在准备阶段,参与者执行了事务,但是还未提交。只有在提交阶段接收到协调者发来的通知后,才进行提交或者回滚。1)事务协调者节点向所有参与者节点发出
正式提交(commit)
的请求;
2)参与者节点正式完成操作,并释放在整个事务期间内占用的资源;
3)参与者节点向协调者节点发送ACK完成消息;
4)事务协调者节点收到所有参与者节点反馈的ACK完成消息后,完成事务。
- 2PC优缺
-
优点
尽量保证了数据的强一致,适合对数据强一致要求很高的关键领域。(其实也不能100%保证强一致,如宕机) -
缺点
-
性能问题:执行过程中,所有参与节点都是事务阻塞型的。当参与者占有公共资源时,其他第三方节点访问公共资源不得不处于阻塞状态。
-
可靠性问题:参与者发生故障。协调者需要给每个参与者额外指定超时机制,超时后整个事务失败。协调者发生故障。参与者会一直阻塞下去。需要额外的备机进行容错。
-
数据一致性问题:二阶段无法解决的问题如协调者在发出commit消息之后宕机,而唯一接收到这条消息的参与者同时也宕机了。那么即使协调者通过选举协议产生了新的协调者,这条事务的状态也是不确定的,没人知道事务是否被已经提交。
-
实现复杂:牺牲了可用性,对性能影响较大,不适合高并发高性能场景。
-
-
3、三阶段提交(3PC)
三阶段提交协议是二阶段提交协议的改进版本,其有两个改动点。
1)在协调者和参与者中都引入超时机制;
2)在第一阶段和第二阶段中插入一个准备阶段,保证了在最后提交阶段之前各参与节点的状态是一致的。
即除了引入超时机制之外,3PC把2PC的准备阶段再次一分为二,这样三阶段提交就有CanCommit、PreCommit 和 DoCommit 三个阶段。
-
阶段1:CanCommit
- 事务询问:协调者向参与者发送一个CanCommit事务请求,询问是否可以执行事务提交操作,开始等待参与者的响应。
- 参与者向协调者反馈事务询问响应:参与者根据自身情况,反馈YES响应,进入预备状态,否则返回NO响应。
-
阶段2:PreCommit
-
返回yes情况:
- 1)协调者向所有参与者发送PreCommit请求,进入准备阶段;
- 2)参与者收到PreCommit请求后,执行事务操作,将undo和redo信息记录到日志中。
- 3)各参与者向协调者反馈事务执行响应:成功响应ACK,同时等待最终指令:提交还是终止。
-
返回no情况(中断事务):
- 1)任一参与者向协调者反馈了 NO响应 或者等待 超时 之后,协调者无法接收到所有参与者反馈响应,那么中断事务。
- 2)发送中断请求(abort请求)。
- 3)参与者收到协调者abort请求或者等待协调者请求超时,参与者中断事务。
-
-
阶段3:DoCommit
- 同步处理:
- 发送提交请求:协调者正常工作状态,接收到来自所有参与者的ACK响应,那么它将从预提交状态转换为提交状态,向所有参与者发送DoCommit请求。
- 事务提交:参与者收到DoCommit请求后,会正式执行事务提交操作,完成提交后,释放事务资源。
- 反馈事务提交结果:参与者完成事务提交之后,向协调者发送ACK消息。
- 完成事务:协调者收到所有参与者反馈的ACK消息后,完成事务。
- 回滚处理:
- 发送中断请求:协调者向所有参与者发送abort请求。
- 事务回滚:参与者收到abort请求后,利用 阶段2中的undo日志来执行事务回滚操作,完成回滚,释放资源。
- 反馈事务回滚结果:参与者完成了事务回滚后,向协调者发送ACK消息。
- 协调者收到所有参与者反馈的ACK消息后,中断事务。
- 同步处理:
4、Seata分布式事务方案
Seata 是一款开源的分布式事务解决方案,致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式,为用户打造一站式的分布式解决方案。
-
Seata术语
- TC(事务协调者):维护全局和分支事务的状态,驱动全局事务提交或回滚。
- TM(事务管理器):定义全局事务的范围:开始全局事务、提交或回滚全局事务
- RM(管理分支事务处理的资源):与TC交谈以注册分支事务和报告分支事务的状态,并驱动分支事务提交或回滚。
-
Seata的2PC方案
- 一阶段:业务数据和回滚日志记录在同一个本地事务中提交,释放本地锁和连接资源。
- 二阶段:提交异步化,非常快速地完成。回滚通过一阶段的回滚日志进行反向补偿。
- 一阶段本地事务提交前,需要确保先拿到 全局锁 。拿不到全局锁 ,不能提交本地事务。
- 拿全局锁的尝试被限制在一定范围内,超出范围将放弃,并回滚本地事务,释放本地锁。
- 在数据库本地事务隔离级别读已提交或以上的基础上,Seata(AT 模式)的默认全局隔离级别是 读未提交
- 如果应用在特定场景下,必需要求全局的 读已提交 ,目前 Seata 的方式是通过 SELECT FOR UPDATE 语句的代理。
-
Seata执行流程分析
-
每个 RM 使用 DataSourceProxy 链接数据路,目的是使用 ConnectionProxy,使用数据源和数据代理的目的是在第一阶段将 undo_log 和业务数据放在一个本地事务提交,这样就保存了只要有业务操作就一定有 undo_log
-
在第一阶段 undo_log 中存放了数据修改前后修改后的值,为事务回滚做好准别,所以第一阶段完成就已经将分支事务提交了,也就释放了锁资源
-
TM 开启全局事务开始,将 XID全局事务ID 放在事务上下文中,通过 feign 调用也将 XID 传入下游分支事务,每个分支事务将自己的 Branch ID 分支事务ID与 XID 关联
-
第二阶段全局事务提交,TC会通知各分支参与者提交分支事务,在第一阶段就已经提交了分支事务,这里各参与者只需要删除undo_log即可,并且可以异步执行,第二阶段很快可以完成
-
如果某一个分支事务异常,第二阶段就全局事务回滚操作,TC会通知各分支参与者回滚分支事务,通过 XID 和 Branch-ID 找到对应的回滚日志,通过回滚日志生成的反向SQL并执行,以完成分支事务回滚到之前
-