Seata核心组件
- TC（Transaction Coordinator）事务协调器，独立部署的 seata server
- TM（Transaction Manager）事务管理器，是事务的发起者（某个微服务）
- RM（Reource Manager）资源管理器，事务的参与者，也就是某个数据库
AT模型
- 每个数据库都会新建一张存储undo log的表
- TM向TC申请开启全局事务，生成一个全局唯一的XID
- TM将执行本地事务和插入回滚日志记录UNDO LOG放在同一个本地事务中执行，RM执行获取RM本地锁，TM向TC获取全局锁（为了保证写隔离，同一份数据修改需要申请同一个全局锁）并注册分支事务，然后提交本地事务，一阶段完成
- TM管理查看所有分支事务是否都成功，如果成功启动一个异步任务删除UNDO LOG，如果失败则开启一个本地事务，通过XID等信息查找到UNDO LOG，然后进行对比生成回滚语句，进行数据回滚，二阶段完成后释放全局锁
- 可能存在的问题
- 因为都会和TC交互，这里可能存在性能瓶颈
- 对同一个全局锁的竞争可能会出现大量任务失败，如：事务t1执行完第一阶段提交了本地事务和undo log，事务t2获取本地锁执行了本地事务，等待获取全局锁进行提交，此时事务t1失败了需要进行回滚，会等待获取本地锁，因为t1和t2是修改的统一数据所以本地锁和全局锁都是同一把，就会出现t2等待全局锁超时事务失败释放本地锁，t1获取本地锁回滚成功
TCC模型
主要说说TCC的三种异常场景
- 幂等：因为TCC二阶段的cconfirm和cancel被要求执行直到成功，因此可能被多次调用
- 空回滚：try还没有执行，就已经执行了cancel，没有资源需要回滚
- 资源悬挂：try还没有执行，就已经执行了空回滚cancel，然后执行try资源被锁定了，后续也没有释放/使用资源的操作
- 解决方案：利用事务状态控制记录作为控制手段，事务表中每个阶段都会有不同的状态，根据控制记录和当前调用的事务阶段检查当前是否陷入了异常场景，状态：INIT（初始执行完try执行）、CONFIRMED(已提交)、ROLLBACKED(已回滚)
SAGA模型
是长事务的解决方案，适用于业务流程长且需要保证事务最终一致性的业务系统。正向和逆向两个过程都由业务代码实现，因此可以对接各种老系统，不需要考虑历史架构问题；在整个业务流程中无锁、性能高、不保证事务的隔离（会有脏读）
和电商订单系统中的最终一致性+流程编排功能流程类型，不过自研的组合是依赖于当前JVM进程，seata是依赖于seata server作为集群
