Seata分布式事务

• 名词解释

1. TC（Transaction Coordinator）事务协调者：维护全局和分支事务的状态，协调全局事务提交或回滚。

2. TM（Transaction Manager）事务管理器：定义全局事务的范围、开始全局事务、提交或回滚全局事务。

3. RM（Resource Manager）资源管理器：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

---

四种模式

1. AT（适用于基于关系型数据库的大多数分布式场景）

默认模式，弱一致性，基于全局锁隔离，无代码侵入。在AT模式下，用户只需关注自己的业务SQL，Seata会自动生成事务的二阶段提交和回滚操作。

在一阶段，Seata 会拦截“业务 SQL”，首先解析 SQL 语义，找到“业务 SQL”要更新的业务数据，在业务数据被更新前，将其保存成“before image”，然后执行“业务 SQL”更新业务数据，在业务数据更新之后，再将其保存成“after image”，最后生成行锁。以上操作全部在一个数据库事务内完成，这样保证了一阶段操作的原子性。

二阶段如果是提交的话，因为“业务 SQL”在一阶段已经提交至数据库， 所以 Seata 框架只需将一阶段保存的快照数据和行锁删掉，完成数据清理即可。

二阶段如果是回滚的话，Seata 就需要回滚一阶段已经执行的“业务 SQL”，还原业务数据。回滚方式便是用“before image”还原业务数据；但在还原前要首先要校验脏写，对比“数据库当前业务数据”和 “after image”，如果两份数据完全一致就说明没有脏写，可以还原业务数据，如果不一致就说明有脏写，出现脏写就需要转人工处理。

2. XA（适用于对一致性、隔离性有高要求的业务）

强一致性，基于数据库隔离，无代码侵入。

3. TCC（适用于对性能要求较高，有非关系型数据库参与的业务）

弱一致性，性能最好，基于资源预留隔离，不需要依赖关系型数据库。但代码入侵度高，try、confirm、canel需要人工手写，而且需要考虑空悬挂、空回滚、幂等性判断，较为复杂。

• Try: 判断是否有可用数据，足够则冻结可用数据。

• Confirm: 完成资源的操作业务；要求try成功，confirm一定要成功。

• Cancel: 预留资源释放，可以理解为try方向操作。

阶段1：检查资源是否足够，足够则冻结资源，执行Try方法

阶段2：执行成功，则执行Confirm方法删除冻结资源。执行失败，执行Cancel逻辑，恢复冻结资源

4. Seaga（适用于业务流程长，参与者包含其它公司或遗留系统服务的业务）

最终一致性，无隔离。有代码侵入，需要编写状态机和补偿业务。性能好。