本文共 1863 字，大约阅读时间需要 6 分钟。
两个内容：
1.Seata 原理
AT模式(业务侵入小)
Seata AT模式是基于XA事务演进而来的一个分布式事务中间件，XA是一个基于数据库实现的分布式事务协议，本质上和两阶段提交一样，需要数据库支持，Mysql5.6以上版本支持XA协议，其他数据库如Oracle，DB2也实现了XA接口角色如下
Branch就是指的分布式事务中每个独立的本地局部事务
第一阶段
Seata 的 JDBC 数据源代理通过对业务 SQL 的解析，把业务数据在更新前后的数据镜像组织成回滚日志，利用 本地事务 的 ACID 特性，将业务数据的更新和回滚日志的写入在同一个 本地事务 中提交。这样，可以保证：任何提交的业务数据的更新一定有相应的回滚日志存在
基于这样的机制，分支的本地事务便可以在全局事务的第一阶段提交，并马上释放本地事务锁定的资源
这也是Seata和XA事务的不同之处，两阶段提交往往对资源的锁定需要持续到第二阶段实际的提交或者回滚操作，而有了回滚日志之后，可以在第一阶段释放对资源的锁定，降低了锁范围，提高效率，即使第二阶段发生异常需要回滚，只需找对undolog中对应数据并反解析成sql来达到回滚目的
同时Seata通过代理数据源将业务sql的执行解析成undolog来与业务数据的更新同时入库，达到了对业务无侵入的效果
第二阶段
如果决议是全局提交，此时分支事务此时已经完成提交，不需要同步协调处理（只需要异步清理回滚日志），Phase2 可以非常快速地完成
2.Seata 源码分析：
重要流程如下：
拿到我们的主键，拿到更新的字段，
拿到更新的where 添加：
模板方法:
1.主要看update 方法，
一张表描述另一张表：
row_key,xid,table-name,bracnhedID:
2.分布式分析：
模板方法：
全局提交
----------------------------------------
总得来说就是分为如下几步
业务方调用各个微服务的try()方法，执行资源检查及预留操作
当所有try()方法均执行成功时，对全局事物进行提交，即由事物管理器调用每个微服务的confirm()方法 当任意一个方法try()失败(预留资源不足，抑或网络异常，代码异常等任何异常)，由事物管理器调用每个微服务的cancle()方法对全局事务进行回滚 资源预留、提交、回滚都由业务方编码控制写在try()、confirm()、cancle()中关键点就是： TCC事务协调器如何知道在业务方调用各个微服务的try()后，是该调用confirm还是cancle方法，以及具体调用哪个资源管理器(RM)的方法
至此第二个问题，TC如何找到该调用哪些机器上服务的confirm方法，rollback方法也解决了
基本思路就是TM发起提交请求（带有xid）
TC通过xid找到全局session，再取出所有的分支session 通过分支session里的resourceId，去缓存中找到缓存的rpcContext对象，取出对应channel，建立通信 总结一下全局事务提交的大致流程业务方调用微服务无异常，通过TM发起事务提交请求
TC接收到事务提交请求后，通过Xid找到全局事务，再取出所有的分支事务 遍历分支事务，发出分支事务提交请求 TCC资源管理器RM接收到提交请求后，从本地TCCResource缓存中根据resourceId取出对应方法bean，反射调用commit方法
源码分析：
参考博文：
转载地址：https://blog.csdn.net/xiamaocheng/article/details/104575827 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！
发表评论
最新留言
关于作者
