两篇文章全面理解分布式事务问题(1) 刚性事务

最新推荐文章于 2024-01-15 17:09:58 发布

代码届彭于晏

最新推荐文章于 2024-01-15 17:09:58 发布

阅读量419

点赞数

分类专栏： java 框架

本文链接：https://blog.csdn.net/m0_37139189/article/details/102941281

版权

框架同时被 2 个专栏收录

74 篇文章 0 订阅

订阅专栏

java

56 篇文章 2 订阅

订阅专栏

关于ACID,CAP和BASE这边就不详细说明了，想了解的可以找网上的相关文章。

分布式事务分为刚性事务和柔性事务两种类别，根据CAP理论刚性事务是会舍弃掉A，保证CP

刚性事务

严格一致性
执行时间短
实时性要求高

首先，很自然的，我们可以把一个分布式事务理解成一个包含了若干 分支事务 的 全局事务。全局事务 的职责是协调其下管辖的 分支事务 达成一致，要么一起成功提交，要么一起失败回滚。此外，通常 分支事务 本身就是一个满足 ACID 的 本地事务。这是我们对分布式事务结构的基本认识，与 XA 是一致的。

1.两阶段提交方案/XA方案

两阶段提交会引入两个组件:

1.全局事务协调者（Cooradinator）

2.参与者（Participant）

一阶段：

a.Cooradinator向所有参与者Participant发出询问，是否可以提交事务

b.各参与者执行本地事务操作，并且将undo和redo日志写入到本地事务日志中

c.各参与者将事务执行结果反馈给Cooradinator，成功反馈yes，失败反馈no。

二阶段：

Cooradinator根据各参与者反馈的情况执行不同的策略；

情况一：如果全部参与者反馈yes，Cooradinator向所有参与者发出commit命令，所有参与者执行redo中的内容，提交本地事务，并且反馈ack给Cooradinator，cooradinator在收到所有ack请求之后释放资源。即完成事务提交

情况二：如果其中有一个参与者反馈no，Cooradinator向所有参与者发出rollback命令，所有参与者执行undo中的内容，回滚事务，并且反馈ack给Cooradinator，cooradinator在收到所有ack请求之后释放资源。即完成事务回滚

问题

1) 性能问题：所有参与者在事务提交阶段处于同步阻塞状态，占用系统资源，容易导致性能瓶颈。

2) 可靠性问题：如果协调者存在单点故障问题，或出现故障，提供者将一直处于锁定状态。

3) 数据一致性问题：在阶段 2 中，如果出现协调者和参与者都挂了的情况，有可能导致数据不一致。

优点：尽量保证了数据的强一致，适合对数据强一致要求很高的关键领域。（其实也不能100%保证强一致）。

缺点：实现复杂，牺牲了可用性，对性能影响较大，不适合高并发高性能场景。

用一张图来描述2PC的场景

2.3PC解决方案

2PC方案存在两个比较严重的问题，一个是同步阻塞范围大，二是阶段二中协调者和参与者同时挂掉，会出现数据不一致，

3PC同样有两个组件：

协调者和参与者

阶段一：

a.协调者询问所有参与者是否可以提交事务（canCommit）

b.参与者收到请求之后根据自身情况反馈信yes或者no

阶段二：

情况一：如果阶段一全部反馈yes，协调者向所有参与者发出preCommit请求，所有参与者写redo和undo日志。并且反馈ack给协调者 yes或者no

情况二：

只要有一个参与者反馈 no，或者等待超时后协调者尚无法收到所有提供者的反馈，即中断事务

a) 协调者向所有参与者发出 abort 请求。

b) 无论收到协调者发出的 abort 请求，或者在等待协调者请求过程中出现超时，参与者均会中断事务。

阶段三：，根据阶段二反馈的结果

情况 1：所有参与者均反馈 ack 响应，执行真正的事务提交

a) 如果协调者处于工作状态，则向所有参与者发出 do Commit 请求。

b) 参与者收到 do Commit 请求后，会正式执行事务提交，并释放整个事务期间占用的资源。

c) 各参与者向协调者反馈 ack 完成的消息。

d) 协调者收到所有参与者反馈的 ack 消息后，即完成事务提交。

情况2：只要有一个参与者反馈 no，或者等待超时后协调组尚无法收到所有提供者的反馈，即回滚事务。

a) 如果协调者处于工作状态，向所有参与者发出 rollback 请求。

b) 参与者使用阶段 1 中的 undo 信息执行回滚操作，并释放整个事务期间占用的资源。

c) 各参与者向协调组反馈 ack 完成的消息。

d) 协调组收到所有参与者反馈的 ack 消息后，即完成事务回滚。

优点：相比二阶段提交，三阶段提交降低了阻塞范围，在等待超时后协调者或参与者会中断事务。避免了协调者单点问题。阶段 3 中协调者出现问题时，参与者会继续提交事务。

缺点：数据不一致问题依然存在，当在参与者收到 preCommit 请求后等待 do commite 指令时，此时如果协调者请求中断事务，而协调者无法与参与者正常通信，会导致参与者继续提交事务，造成数据不一致。

3. TCC框架下的事务控制

条件：

需要实现确认和补偿逻辑

需要支持幂等

处理流程：

a) Try 阶段主要是对业务系统做检测及资源预留。

这个阶段主要完成：

完成所有业务检查( 一致性 ) 。

预留必须业务资源( 准隔离性 ) 。

Try 尝试执行业务。

b) Confirm 阶段主要是对业务系统做确认提交。

Try阶段执行成功并开始执行 Confirm阶段时，默认 Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。

c) Cancel 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。

优点：

性能提升：具体业务来实现控制资源锁的粒度变小，不会锁定整个资源。

数据最终一致性：基于 Confirm 和 Cancel 的幂等性，保证事务最终完成确认或者取消，保证数据的一致性。

可靠性：解决了 XA 协议的协调者单点故障问题，由主业务方发起并控制整个业务活动，业务活动管理器也变成多点，引入集群。

缺点：TCC 的 Try、Confirm 和 Cancel 操作功能要按具体业务来实现，业务耦合度较高，提高了开发成本。

4.阿里Fescar框架

上面说的刚性事务解决方案，2PC或者3PC性能上太差，而TCC对代码侵入性又太大，有没有一种框架对代码侵入性少，而且性能也比较好的呢。下面就介绍下阿里的Fescar框架

其次，与 XA 的模型类似，我们定义 3 个组件来协议分布式事务的处理过程。

FESCAR Model

Transaction Coordinator (TC)：事务协调器，维护全局事务的运行状态，负责协调并驱动全局事务的提交或回滚。

Transaction Manager (TM)：控制全局事务的边界，负责开启一个全局事务，并最终发起全局提交或全局回滚的决议。

Resource Manager (RM)：控制分支事务，负责分支注册、状态汇报，并接收事务协调器的指令，驱动分支（本地）事务的提交和回滚。

一个典型的分布式事务过程：

TM 向 TC 申请开启一个全局事务，全局事务创建成功并生成一个全局唯一的 XID。

XID 在微服务调用链路的上下文中传播。

RM 向 TC 注册分支事务，将其纳入 XID 对应全局事务的管辖。

TM 向 TC 发起针对 XID 的全局提交或回滚决议。

TC 调度 XID 下管辖的全部分支事务完成提交或回滚请求。

之前提到过2PC等资源一直要等到第二阶段完成之后才会释放资料，比如数据库连接，这样会严重影响性能。而Fescar是这么做的：

Fescar在第一阶段提交之后就，分支事务就释放资源。但是全局事务锁依然存在在，这样可以保证不脏读。

Fescar是如何保证分支事务回滚的呢?

首先，应用需要使用 Fescar 的 JDBC 数据源代理，也就是 Fescar 的 RM。

Data Source Proxy

Phase1：

Fescar 的 JDBC 数据源代理通过对业务 SQL 的解析，把业务数据在更新前后的数据镜像组织成回滚日志，利用 本地事务 的 ACID 特性，将业务数据的更新和回滚日志的写入在同一个 本地事务 中提交。

这样，可以保证：任何提交的业务数据的更新一定有相应的回滚日志存在。

Branch Transaction with UNDO LOG

基于这样的机制，分支的本地事务便可以在全局事务的 Phase1 提交，马上释放本地事务锁定的资源。

Phase2：

如果决议是全局提交，此时分支事务此时已经完成提交，不需要同步协调处理（只需要异步清理回滚日志），Phase2 可以非常快速地完成。

Global Commit

如果决议是全局回滚，RM 收到协调器发来的回滚请求，通过 XID 和 Branch ID 找到相应的回滚日志记录，通过回滚记录生成反向的更新 SQL 并执行，以完成分支的回滚。

Global Rollback

--------------------------------------------------------------

下面看一下Fescar的集中模式

AT模式，自动挡模式：

两阶段提交协议的演变：

一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。

二阶段：

提交异步化，非常快速地完成。

回滚通过一阶段的回滚日志进行反向补偿

写隔离

一阶段本地事务提交前，需要确保先拿到 全局锁 。
拿不到 全局锁 ，不能提交本地事务。
拿 全局锁 的尝试被限制在一定范围内，超出范围将放弃，并回滚本地事务，释放本地锁。

以一个示例来说明：

两个全局事务 tx1 和 tx2，分别对 a 表的 m 字段进行更新操作，m 的初始值 1000。

tx1 先开始，开启本地事务，拿到本地锁，更新操作 m = 1000 - 100 = 900。本地事务提交前，先拿到该记录的 全局锁 ，本地提交释放本地锁。 tx2 后开始，开启本地事务，拿到本地锁，更新操作 m = 900 - 100 = 800。本地事务提交前，尝试拿该记录的 全局锁 ，tx1 全局提交前，该记录的全局锁被 tx1 持有，tx2 需要重试等待 全局锁 。

Write-Isolation: Commit

tx1 二阶段全局提交，释放 全局锁 。tx2 拿到 全局锁 提交本地事务。

Write-Isolation: Rollback

如果 tx1 的二阶段全局回滚，则 tx1 需要重新获取该数据的本地锁，进行反向补偿的更新操作，实现分支的回滚。

此时，如果 tx2 仍在等待该数据的 全局锁，同时持有本地锁，则 tx1 的分支回滚会失败。分支的回滚会一直重试，直到 tx2 的 全局锁 等锁超时，放弃 全局锁 并回滚本地事务释放本地锁，tx1 的分支回滚最终成功。

因为整个过程 全局锁 在 tx1 结束前一直是被 tx1 持有的，所以不会发生脏写的问题。

读隔离

在数据库本地事务隔离级别 读已提交（Read Committed） 或以上的基础上，Seata（AT 模式）的默认全局隔离级别是 读未提交（Read Uncommitted） 。

如果应用在特定场景下，必需要求全局的 读已提交 ，目前 Seata 的方式是通过 SELECT FOR UPDATE 语句的代理。

Read Isolation: SELECT FOR UPDATE

SELECT FOR UPDATE 语句的执行会申请 全局锁 ，如果 全局锁 被其他事务持有，则释放本地锁（回滚 SELECT FOR UPDATE 语句的本地执行）并重试。这个过程中，查询是被 block 住的，直到 全局锁 拿到，即读取的相关数据是 已提交 的，才返回。

出于总体性能上的考虑，Seata 目前的方案并没有对所有 SELECT 语句都进行代理，仅针对 FOR UPDATE 的 SELECT 语句。

工作机制

以一个示例来说明整个 AT 分支的工作过程。

业务表：product

Field	Type	Key
id	bigint(20)	PRI
name	varchar(100)
since	varchar(100)

AT 分支事务的业务逻辑：

update product set name = 'GTS' where name = 'TXC';

一阶段

过程：

解析 SQL：得到 SQL 的类型（UPDATE），表（product），条件（where name = 'TXC'）等相关的信息。
查询前镜像：根据解析得到的条件信息，生成查询语句，定位数据。

select id, name, since from product where name = 'TXC';

得到前镜像：

id	name	since
1	TXC	2014

执行业务 SQL：更新这条记录的 name 为 'GTS'。
查询后镜像：根据前镜像的结果，通过主键定位数据。

select id, name, since from product where id = 1`;

得到后镜像：

id	name	since
1	GTS	2014

插入回滚日志：把前后镜像数据以及业务 SQL 相关的信息组成一条回滚日志记录，插入到 UNDO_LOG 表中。

{
	"branchId": 641789253,
	"undoItems": [{
		"afterImage": {
			"rows": [{
				"fields": [{
					"name": "id",
					"type": 4,
					"value": 1
				}, {
					"name": "name",
					"type": 12,
					"value": "GTS"
				}, {
					"name": "since",
					"type": 12,
					"value": "2014"
				}]
			}],
			"tableName": "product"
		},
		"beforeImage": {
			"rows": [{
				"fields": [{
					"name": "id",
					"type": 4,
					"value": 1
				}, {
					"name": "name",
					"type": 12,
					"value": "TXC"
				}, {
					"name": "since",
					"type": 12,
					"value": "2014"
				}]
			}],
			"tableName": "product"
		},
		"sqlType": "UPDATE"
	}],
	"xid": "xid:xxx"
}

提交前，向 TC 注册分支：申请 product 表中，主键值等于 1 的记录的 全局锁 。
本地事务提交：业务数据的更新和前面步骤中生成的 UNDO LOG 一并提交。
将本地事务提交的结果上报给 TC。

二阶段-回滚

收到 TC 的分支回滚请求，开启一个本地事务，执行如下操作。
通过 XID 和 Branch ID 查找到相应的 UNDO LOG 记录。
数据校验：拿 UNDO LOG 中的后镜与当前数据进行比较，如果有不同，说明数据被当前全局事务之外的动作做了修改。这种情况，需要根据配置策略来做处理，详细的说明在另外的文档中介绍。
根据 UNDO LOG 中的前镜像和业务 SQL 的相关信息生成并执行回滚的语句：

update product set name = 'TXC' where id = 1;

提交本地事务。并把本地事务的执行结果（即分支事务回滚的结果）上报给 TC。

二阶段-提交

收到 TC 的分支提交请求，把请求放入一个异步任务的队列中，马上返回提交成功的结果给 TC。
异步任务阶段的分支提交请求将异步和批量地删除相应 UNDO LOG 记录。

-------------------------------

代码届彭于晏

关注

0
点赞
踩
2

收藏

觉得还不错? 一键收藏
0
评论
两篇文章全面理解分布式事务问题(1) 刚性事务

关于ACID,CAP和BASE这边就不详细说明了，想了解的可以找网上的相关文章。分布式事务分为刚性事务和柔性事务两种类别，根据CAP理论刚性事务是会舍弃掉A，保证CP刚性事务严格一致性执行时间短实时性要求高首先，很自然的，我们可以把一个分布式事务理解成一个包含了若干分支事务的全局事务。全局事务的职责是协调其下管辖的分支事务达成一致，要么一起成功提交，要么一起失败回...
复制链接

扫一扫