Alibaba分布式事务组件Seata实战
事务
本地事务
- 对于操作单一数据库的场景下的事务,ACIO特性是数据库直接支持的
分布式事务
- 在分布式情况下,需要的操作资源分布在多个资源服务上,而应用需要保证对于多个资源服务器的数据操作要么全部成功要么全部失败,本质上是为了保证不同服务的数据一致性
- 应用场景
- 跨库事务
- 分库分表
- 跨服务调用
- 应用场景
- 如何实现分布式事务
- 两阶段提交(2PC)
- 将提交过程分为准备阶段和提交,全局事务的ACIO依赖于资源管理器
- 第一阶段
- 事务管理器™通知各个资源管理器(RM)准备提交各自的事务
- 第二阶段
- 事务管理器根据所有资源管理器的反馈情况来决定提交还是回滚,如果有一个没满足要求就通过所有资源管理器进行回滚
- 第一阶段
存在的问题
- 同步阻塞
- 在准备阶段,第一时间收到通知的服务会锁定资源,直到提交才会释放
- 单点故障
- 一旦事务管理器出现故障,参与者都会阻塞下去,特别是提交阶段
- 数据不一致
- 如果提交阶段出现崩溃,会导致一部分服务事务已提交导致数据不一致
- 同步阻塞
- 将提交过程分为准备阶段和提交,全局事务的ACIO依赖于资源管理器
- 两阶段提交(2PC)
Seata
- 阿里开源的分布式事务解决方案,提供了AT、TCC、SAGA和XA事务模式,AT模式首推
Seata的三大角色
-
三大角色
-
TC(事务协调者)
- 维护全局和分支事务的状态,驱动全局事务的提交或回滚
-
TM(事务管理器)
- 开始全局事务、提交或回滚全局事务
-
RM(资源管理器)
- 管理分支事务处理的资源,与TC交谈以注册分支事务和报告分支事务的状态,并驱动分支事务提交或回滚
-
-
注意
- TC为单独部署的服务端,TM和RM是嵌入应用的客户端
AT模式
-
AT模式的核心是对业务无侵入的,是一种改进后的2PC模式
-
设计思路
- 第一阶段
- 业务数据和回滚日志会在同一本地事务种提交,释放本地锁和连接资源,核心在于对于业务sql的解析转化成undolog并同时入库
- 第二阶段
- 分布式事务操作成功之后,TC通知RM异步删除undolog
- 分布式事务操作失败之后,TM向TC发送回滚请求,RM收到TC的请求后,通过XID和Branch ID找到对应的回滚日志记录,通过该记录生成反向更新SQL执行来完成回滚
- 第一阶段
XA模式
- XA模式是一个强一致性的2PC模式
- 当各个分支事务完成之后,不立即提交,而是等待各个分支事务将自己的事务状态反馈给TC,由TC根据所有分支事务的状态决定是提交还是回滚,每个事务的执行需要等待其他事务的执行结果,因此性能可能受到影响
TCC模式
- TCC模式是一种侵入式的2PC模式,每个分支的事务都需要具备自己的两阶段,但是不依赖于数据库,适用于复杂业务场景下的分布式事务
SAGA模式
- SAGA模式是基于状态机引擎的2PC模式,通过将长事务拆分为多个本地子事务以及相应的补偿操作来保证数据一致性