seata 的 4大事务模式对比

seata分布式事务框架：

github 官方模式案例下载地址

seata中角色的定义：
	TM：事务管理者   （向TC发起一个请求，给全局事务定义一个统一的XID，代表在一个全局事务中）定义全局事务，开启提交或者回滚全局事务
	RM：资源管理者   （分支事务）相当于我们的 微服务，在TC上注册分支事务及通知本地事务执行的状态，并驱动分支事务的提交和回滚
	TC：事务协调者    （指定告诉那个分支事务对应的操作）维护全局事务，驱动全局事务的提交或者回滚

seata就是在2pc（即两阶段提交协议）的基础上的一种加强优化。seata的两阶段提交处理

执行阶段：执行本地分支事务，并保证执行结果是可回滚（rollbckable）和持久的（durable）  
完成阶段：根据执行阶段的结果形成决议，应用通过 TM 发出的全局提交回滚的请求给 TC ，TC命令RM 驱动分支事务进行 commit 或 rollback。

Seata 中4大事务模式之间的区别：

AT：
	~ 基于sql层面，进行sql解析，并记录sql执行前后的数据，持久化到 undo.log（修改前数据）和redo.log（修改后数据）
	~ AT模式的RM在本地事务执行完成后就会提交事务，不会占用本地资源
	~ 最终一致性，可能会出现脏读
	~ 业务无侵入
XA：
	~ 基于XA协议，全局一致性，没有数据日志的记录，由 XA 分支来执行 sql 进入准备状态，通知 TC ，由进行对各个（RM）分支事务处理
	~ XA模式则是在所有的本地事务执行完成后，TC才发送指令让所有的RM提交事务、释放本地锁
	~ 强一致性，因为都是它一直占着，不全部执行完就不放。因此XA模式是不会出现脏读
	~ 业务无侵入
XA 和 AT 共同点：基于 支持本地 ACID 事务 的 关系型数据库
TCC：
	~ 不依赖于底层数据资源的事务支持
	~ 侵入性较强，需自己编写事务控制逻辑
	~ 全局基本没有锁，性能较强
	~ 业务侵入
Sage：
	~ 基于事件来驱动的，各个参与者之间的是异步执行的，Saga模式是一种长事务解决方案
	~ 业务侵入

Seata的事务：

	1，TM 向 TC 请求发起（Begin）、提交（Commit）、回滚（Rollback）申请开启一个全局事务，TC会创建一个全局事务并返回一个id：XID
	2，TM 把代表全局事务的 XID 绑定到分⽀事务上
	3，RM携带当前的Xid向TC发起注册请求
	4，RM把分支事务执行的结果上报给 TC
	5，TC 发送分⽀提交（Branch Commit）或分⽀回滚（Branch Rollback）命令给 RM

seata 事务执行流程图：

Seata AT 模式，最终一致性：默认读未提交

	1.执行阶段：执行本地分支事务，并保证执行结果是可回滚（rollbckable）和持久的（durable）
		~ 可回滚（rollbckable）：根据sql运行解析的结果，记录回滚日志，提交事务前获取全局锁，和全局锁本地事务一并提交，释放本地锁和连接资源。
		~ 持久的（durable）：回滚日志和业务sql在同一个本地事务中提交到数据库中。
	2.完成阶段：根据执行阶段的结果形成决议，应用通过 TM 发出的全局提交回滚的请求给 TC ，TC命令RM 驱动分支事务进行 commit 或- rollback
		~ 分支提交：异步删除回滚日志。
		~ 分支回滚：根据回滚日志进行反向补偿更新。	

AT模式 流程图：

XA模式，强一致性：

	执行阶段：
		~ 可回滚（rollbckable）：业务 sql 操作放在XA分支中执行，由资源对 XA 协议的支持来保证可回滚
		~ 持久的（durable）：XA分支完成后，执行 XA prepare，同样由资源对于 XA 协议的支持来保证持久化（即之后任何意外都不会造成无法回滚的情况）
	完成阶段：
		~ 分支提交：执行 XA 分支的 commit
		~ 分支回滚：执行 XA 分支的 rollbck

AT模式 流程图：

TCC 模式：最终一致性

	一阶段 prepare 行为：调用 自定义 的 Try接口中的 逻辑。
	二阶段 commit 行为：调用 自定义 的 Confirm接口中的 逻辑。
	二阶段 rollback 行为：调用 自定义 的 Cancel接口中的 逻辑。

TCC模式 流程图：
Sage 模式 最终一致性
后续弥补，是在不好意思！！！