分布式事务——Seata 2PC
Seata介绍
2019 年 1 月,阿里巴巴中间件团队发起了开源项目 Fescar(Fast & EaSy Commit And Rollback),和社区一起共建开源分布式事务解决方案。Fescar 的愿景是让分布式事务的使用像本地事务的使用一样,简单和高效,并逐步解决开发者们遇到的分布式事务方面的所有难题。
Fescar 开源后,蚂蚁金服加入 Fescar 社区参与共建,并在 Fescar 0.4.0 版本中贡献了 TCC 模式。
为了打造更中立、更开放、生态更加丰富的分布式事务开源社区,经过社区核心成员的投票,大家决定对 Fescar 进行品牌升级,并更名为 Seata,意为:Simple Extensible Autonomous Transaction Architecture,是一套一站式分布式事务解决方案。
Seata 融合了阿里巴巴和蚂蚁金服在分布式事务技术上的积累,并沉淀了新零售、云计算和新金融等场景下丰富的实践经验。
Seata分布式事务实现方案
seata中有两种分布式事务实现方案,AT及TCC
- AT模式主要关注多 DB 访问的数据一致性,当然也包括多服务下的多 DB 数据访问一致性问题
- TCC 模式主要关注业务拆分,在按照业务横向扩展资源时,解决微服务间调用的一致性问题
AT模式
本文AT模式基本原理参考:https://www.cnblogs.com/liqbk/p/13630353.html
比如说现在我们有个订单系统:
当用户下订单时,执行以下三步流程:
- 订单系统保存订单
- 订单系统调用库存服务,减少商品库存
- 订单系统调用账户服务,扣减用户金额
这三步要作为一个整体事务进行管理,要么整体成功,要么整体失败。
第一阶段:执行各分支事务
首先我们要理解一些概念:
Transaction Coordinator (TC): 事务协调器,维护全局事务的运行状态,负责协调并驱动全局事务的提交或回滚。
Transaction Manager(TM): 控制全局事务的边界,负责开启一个全局事务,并最终发起全局提交或全局回滚的决议。
Resource Manager (RM): 控制分支事务,负责分支注册、状态汇报,并接收事务协调器的指令,驱动分支(本地)事务的提交和回滚。
然后开始订单系统保存订单流程说明:
- 订单系统开始执行保存订单之前,首先启动
TM
(Transaction Manager,事务管理器),由TM
向TC
申请开启一个全局事务; - 这时
TC
会产生一个全局事务ID,称为 XID,并将 XID 传回TM
,这样就开启了全局事务; - 全局事务开启后,开始执行创建订单的业务。首先执行保存订单,这时会先启动一个
RM
(Resource Manager,资源管理器),并将 XID 从TM
传递给RM
; RM
首先会使用 XID 向TC
注册分支事务,将分支事务纳入对应的全局事务管辖;然后执行保存订单的分支事务了,一旦分支事务执行成功,RM
会上报事务状态给TC
;TC
收到后,会将该状态信息传递到TM
。到此,保存订单过程结束。
调用库存服务,减少商品库存,与订单的执行过程相同。
- 库存服务的 RM 使用 XID 向
TC
进行注册,纳入全局事务管辖; - 执行本地事务成功后上报状态,
TC
会将状态发送给TM
。
第二阶段:控制全局事务最终提交或回滚
现在,TM
(全局事务管理器)收集齐了全部分支事务的成功状态,它会进行决策。
- 如果全部分支事务都为成功状态,那么就会向
TC
发送全局事务的提交请求;然后,TC
会向所有RM
发送提交操作指令,RM
会完成最终提交操作。到此,全局事务全部提交完成。 - 如果有分支事务执行失败,
TM
会进行决策,确定全局事务失败,向TC
发送全局事务回滚请求;然后,TC
会向所有RM
发送回滚操作指令,RM
会完成最终回滚操作。
具体工作原理?
比如说操作库存信息时,会把旧的库存信息和修改后的库存信息存入一个事务回滚日志表:undo_log表,存入完成后将状态上报给TC
。
到第二阶段的时候,如果最终决定回滚,那么就根据事务回滚日志(undo_log)表的记录,将商品恢复成旧的库存数据并且删除事务回滚日志相应记录;如果最终决定提交,那么直接删除事务日志即可。
TCC模式
在Seata下的TCC模式与常规TCC模式有所不同。常规的TCC模式只有协调者和参与者,而Seata下的TCC模式有着跟AT模式相同的TC
、TM
、RM
。如果对常规TCC模式不清楚的话,可以看我的文章分布式事务。
网上流传较多的都是这张图,我就是用下图进行说明:
大致流程是这样的:
- 全局事务拦截器拦截到
@GlobalTransational
注解,启动TM
(Transaction Manager,事务管理器),由TM
向TC
申请开启一个全局事务,这时TC
会产生一个全局事务ID,称为 XID,并将 XID 传回TM
,这样就开启了全局事务; RM
首先会使用 XID 向TC
注册分支事务,将分支事务纳入对应的全局事务管辖,在prepare
方法执行后向TC
报告分支事务的状态;TC
收到后,会将该状态信息传递到TM
;- 如果执行发生异常则
TM
通知TC
回滚事务,否则TM
通知TC
执行提交事务; TC
收到TM
的提交或回滚通知,遍历各TCC
分支事务,逐个进行提交或回滚。
总结一下,Seata框架下的TCC模式其实就是在原有TCC模式上套了个框架,总体变化并不大。
Seata框架图: