SpringCloud Alibaba Seata
Seata 工作机制
说明
之所以放在后面说工作机制是因为如果一开始就说的话理解困难
所以我们有了前面的列子和说明我们在结合本节内容会收获的多理解相对容易点
分布式事务过程分析
- Seata 分布式事务处理过程-ID+三组件模型
debug
梳理: 术语
先说出现了几个术语XID, TC, TM, RM上图展示了一个分布式事务在Seata的处理过程
- Transaction ID XID: 全局唯一的事务ID
- Transaction Coordinator(TC) : 事务协调器，维护全局事务的运行状态，负责协调并驱动全局事务的提交或回滚
- Transaction Manager™ : 控制全局事务的边界，负责开启一个全局事务，并最终发起全局提交或全局回滚的决议;
- Resource Manager(RM) : 控制分支事务，负责分支注册，状态汇报，并接收事务协调器的指令，驱动分支（本地）事务的提交和回滚
梳理: 执行过程
- TM向TC申请开启一个全局事务，全局事务创建成功并生成一个全局唯一的XID XID在微服务调用链路的上下文中传播;
- RM 向TC注册分支事务，将其纳入XID 对应全局事务的管辖
- TM 向TC 发起针对XID 的全局提交或回滚决议
- TC 调度XID下管辖的全部分支事务完成提交或回滚请求。
Seata 事务模式
- 地址: https://seata.io/zh-cn/
-
AT(默认模式)
-
TCC
-
SAGA
-
XA
AT 无侵入模式
文档: https://seata.io/zh-cn/docs/overview/what-is-seata.html
一阶段加载
在一阶段，Seata 会拦截 业务SQL
- 解析SQL 语义，找到"业务SQL"要更新的业务数据，在业务数据被更新前，将其保存成"before image" (前置镜像)
- 执行"业务SQL"更新业务数据，在业务数据更新之后, 其保存成"after image"/后置镜像
- 最后生成行锁
- 以上操作全部在一个数据库事务内完成，这样保证了一阶段操作的原子性
二阶段提交
- 二阶段如果是顺利提交
- 因为"业务SQL"在一阶段已经提交至数据库，所以Seata 框架只需将一阶段保存的快照数据和行锁删掉，完成数据清理即可
二阶段回滚
- 二阶段如果是回滚的话，Seata 就需要回滚一阶段已经执行的"业务SQL"，还原业务数据。
- 回滚方式便是用"before image"还原业务数据;但在还原前要首先要校验脏写，对比"数据库当前业务数据"和"after image 如果两份数据完全一致就说明没有脏写，可以还原业务数据
- 如果不一致就说明有脏写，出现脏写就需要转人工处理。
AT 事务模式Debug 验证
SEATA 的分布式交易解决方案
