简介
Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。AT模式是阿里首推的模式,阿里云上有商用版本的GTS(Global Transaction Service 全局事务服务)
官网:seata.io/zh-cn/index…
源码: github.com/seata/seata
官方Demo: github.com/seata/seata…
seata版本: v1.4.0
1.1 Seata的三大角色
在 Seata 的架构中，一共有三个角色:
TC (Transaction Coordinator) - 事务协调者维护全局和分支事务的状态，驱动全局事务提交或回滚。
TM (Transaction Manager) - 事务管理器定义全局事务的范围:开始全局事务、提交或回滚全局事务。
RM (Resource Manager) - 资源管理器管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。 其中，TC 为单独部署的 Server 服务端，TM 和 RM 为嵌入到应用中的 Client 客户端。
在 Seata 中，一个分布式事务的生命周期如下:
- TM 请求 TC 开启一个全局事务。TC 会生成一个 XID 作为该全局事务的编号。XID，会在微服务的调用链路中传播，保证将多个微服务 的子事务关联在一起。
- RM 请求 TC 将本地事务注册为全局事务的分支事务，通过全局事务的 XID 进行关联。
- TM 请求 TC 告诉 XID 对应的全局事务是进行提交还是回滚。
- TC 驱动 RM 们将 XID 对应的自己的本地事务进行提交还是回滚。\
1.2 设计思路
AT模式的核心是对业务无侵入，是一种改进后的两阶段提交，其设计思路如图
第一阶段
业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。核心在于对业务sql进行解析，转换成undolog，并同时 入库，这是怎么做的呢?先抛出一个概念DataSourceProxy代理数据源，通过名字大家大概也能基本猜到是什么个操作，后面做具体分析
参考官方文档: seata.io/zh-cn/docs/…
第二阶段
分布式事务操作成功，则TC通知RM异步删除undolog
分布式事务操作失败，TM向TC发送回滚请求，RM 收到协调器TC发来的回滚请求，通过 XID 和 Branch ID 找到相应的回滚日志记 录，通过回滚记录生成反向的更新 SQL 并执行，以完成分支的回滚。
整体执行流程
1.3 设计亮点
相比与其它分布式事务框架，Seata架构的亮点主要有几个:
- 应用层基于SQL解析实现了自动补偿，从而最大程度的降低业务侵入性;
- 将分布式事务中TC(事务协调者)独立部署，负责事务的注册、回滚;
- 通过全锁实现了写隔离与读隔离。
1.4 存在的问题
性能损耗
一条Update的SQL，则需要全局事务xid获取(与TC通讯)、before image(解析SQL，查询一次数据库)、after image(查询一 次数据库)、insert undo log(写一次数据库)、before commit(与TC通讯，判断锁冲突)，这些操作都需要一次远程通讯RPC，而 且是同步的。另外undo log写入时blob字段的插入性能也是不高的。每条写SQL都会增加这么多开销,粗略估计会增加5倍响应时间。
性价比
为了进行自动补偿，需要对所有交易生成前后镜像并持久化，可是在实际业务场景下，这个是成功率有多高，或者说分布式事务失败 需要回滚的有多少比率?按照二八原则预估，为了20%的交易回滚，需要将80%的成功交易的响应时间增加5倍，这样的代价相比于让应 用开发一个补偿交易是否是值得?
全局锁
热点数据
相比XA，Seata 虽然在一阶段成功后会释放数据库锁，但一阶段在commit前全局锁的判定也拉长了对数据锁的占有时间，这个开销 比XA的prepare低多少需要根据实际业务场景进行测试。全局锁的引入实现了隔离性，但带来的问题就是阻塞，降低并发性，尤其是热点 数据，这个问题会更加严重。
回滚锁释放时间
Seata在回滚时，需要先删除各节点的undo log，然后才能释放TC内存中的锁，所以如果第二阶段是回滚，释放锁的时间会更长。 死锁问题
Seata的引入全局锁会额外增加死锁的风险，但如果出现死锁，会不断进行重试，最后靠等待全局锁超时，这种方式并不优雅，也延 长了对数据库锁的占有时间。
