什么是seata
Seata（Simple Extensible Autonomous Transaction Architecture）是一个开源的分布式事务解决方案，它主要用于解决微服务架构下分布式事务问题。Seata 提供了多种分布式事务解决方案，适用于不同场景，以下是其几种主要的解决方案：
1. AT 模式（Automatic Transaction）
特点：AT模式是Seata默认的分布式事务解决方案，主要适用于关系型数据库。
实现原理：AT模式通过代理数据源，在本地事务中自动生成回滚日志，提交事务时生成一个全局事务ID，并将其注册到Seata的事务协调器（TC）。如果事务失败或回滚，则利用保存的回滚日志恢复到事务开始前的状态。
使用场景：适合于业务逻辑相对简单、数据库变更较多的场景。
优点：开发简单，不需要手动编写分支事务的提交和回滚逻辑。
缺点：AT模式主要依赖于Seata对SQL的解析，支持性会随着SQL复杂度增加而降低。
2. TCC 模式（Try-Confirm-Cancel）
特点：TCC 模式是基于业务定义的手动事务补偿模式，需要开发者自己实现 Try、Confirm 和 Cancel 三个方法。
实现原理：
Try：预留资源阶段，进行业务检查并预留资源。
Confirm：确认执行阶段，在Try阶段成功的情况下，正式提交事务。
Cancel：取消执行阶段，在Try阶段失败或需要回滚时，释放预留的资源。
使用场景：适合有复杂业务逻辑和需要精确控制资源的场景，比如支付、订单处理等。
优点：提供了较强的灵活性，可以根据业务需求进行精细化控制。
缺点：开发工作量较大，开发者需要手动编写每个操作的三步流程。
3. SAGA 模式
特点：SAGA 是一种长事务解决方案，适合于长时间运行的分布式事务。
实现原理：
事务被拆分成一系列可以独立提交的子事务，并定义每个子事务的补偿操作。
如果所有子事务都成功，事务就提交；如果某个子事务失败，则根据定义好的补偿机制，逐步逆向执行补偿操作以回滚事务。
使用场景：适合长时间、跨多个业务系统的流程型事务，例如机票、酒店、支付等多步骤的预定场景。
优点：能够处理长事务、复杂业务流程的场景，且可以在每一步操作中定义具体的补偿逻辑。
缺点：补偿逻辑的编写较为繁琐，且需要业务层面有更深入的理解。
4. XA 模式
特点：XA 是一种分布式事务协议，基于两阶段提交（2PC）协议，保证全局数据的一致性。
实现原理：
第一阶段：所有分支事务都先执行准备（Prepare）操作，如果所有分支都准备成功，则进入第二阶段。
第二阶段：如果所有分支都准备成功，则提交（Commit）；如果有一个分支准备失败，则回滚（Rollback）。
使用场景：适合对数据一致性要求高的场景，通常用于支持XA协议的数据库。
优点：能够保证严格的ACID事务特性。
缺点：由于两阶段提交的同步机制，可能会导致性能较差，适合事务量较小的场景。
5. 自定义事务模式
特点：开发者可以基于Seata的框架，结合具体业务场景自定义事务解决方案。
实现原理：结合Seata的事务协调器（TC）和资源管理器（RM），实现特定业务场景的事务逻辑。
使用场景：适合标准模式无法完全满足的复杂场景，或者需要业务和框架深度结合的场景。
优点：灵活性极高，可以根据业务需求自由调整。
缺点：开发成本高，要求开发者对Seata框架有深入理解。
总结
Seata 提供的分布式事务解决方案主要有四种：AT、TCC、SAGA 和 XA 模式，每种模式都有其适用场景和优缺点。选择哪种模式应根据业务的复杂度、性能要求以及对数据一致性的要求来决定：
数据库为主、操作简单：AT 模式。
业务流程复杂、需要手动控制：TCC 模式。
长时间、多步骤事务：SAGA 模式。
数据一致性要求高、XA支持的数据库：XA 模式。
Seata的AT模型
基本流程图
详细流程
一阶段
1.TM向TC注册一个全局事务，并生成一个全局事务ID
2.调用分支事务，在全局事务的上下文中，业务逻辑调用其他微服务，每个微服务会涉及到数据库操作（CRUD）。
- 生成：在每次数据变更操作之前，RM会记录变更前的数据（前镜像）和变更后的数据（后镜像），这些信息会被保存在undo_log表中。
3.注册分支事务，RM会把这些操作向TC注册为分支事务，并关联到相应的全局事务（通过XID标识）。
4.业务操作执行：在成功生成undo log后，数据库操作才会被真正执行。
5.RM向TC报告事务状态
二阶段
1.TM请求全局提交：当业务逻辑确认所有的操作都成功后，TM会向TC发起全局提交请求。
2.检查分支事务状态
3.提交事务或回滚事务
-
提交事务会删除undo_log表中的记录
-
回滚事务会恢复undo_log表中的记录