一，seata是什么
seata是一款开源的分布式事务解决方案，提供了AT、TCC、XA、SAGA事务模式，为用户打造一站式的分布式事务解决方案。
Seata 管理分布式事务的过程主要分为三个组件：事务协调器（TC） 、事务管理器（TM） 和资源管理器（RM） 。事务协调器（TC）: TC 是 Seata 的中心组件，负责维护全局事务的状态，并协调全局提交或回滚。它记录了每个分支事务的状态，并在全局事务结束时决定是提交还是回滚。事务管理器（TM）: TM 负责定义全局事务的范围：开始全局事务、提交或回滚全局事务。它会向 TC 注册全局事务，并在全局事务结束时请求提交或回滚。资源管理器（RM）: RM 负责管理分支事务，它将资源（比如数据库连接）注册到 TC。在分支事务开始时，RM 会将本地事务的状态报告给 TC；在全局事务提交或回滚时，RM 会完成实际的提交或回滚操作。
二，AT模式
1，使用前提
需要基于支持本地ACID事务的关系型数据库，Java应用，通过JDBC访问数据库
2，运行原理
实际上是两阶段提交协议的演变。一阶段，业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和链接资源。二阶段，提交异步化，非常快速地完成，回滚通过一阶段的回滚日志进行反向补偿。
写隔离：一阶段提交本地事务前，需要确保先拿到全局锁。拿不到全局锁不能提交本地事务。获取全局锁的尝试被限制在一定范围内，超出范围将放弃，并回滚本地事务，释放本地锁。
读隔离：本地数据库为读已提交或以上基础上，Seata AT模式的默认全局隔离级别是读未提交。如果应用在特定场景下，必需要求全局的读已提交 ，目前 Seata 的方式是通过SELECT FOR UPDATE 语句的代理。SELECT FOR UPDATE 语句的执行会申请全局锁，如果全局锁被其他事务持有，则释放本地锁（回滚 SELECT FOR UPDATE 语句的本地执行）并重试。这个过程中，查询是被block住的，直到全局锁拿到，即读取的相关数据是已提交的，才返回。出于总体性能上的考虑，Seata 目前的方案并没有对所有 SELECT 语句都进行代理，仅针对FOR UPDATE的SELECT语句。
优势：无侵入性，开发者可以像处理本地事务一样处理分布式事务，无需修改业务逻辑。易于使用，Seata AT模式提供了简单易用的编程模型，减少了开发者在分布式事务处理上的负担。强一致性，提供了数据的强一致性保障，确保事务要么全部提交，要么全部回滚。缺点：性能开销，由于需要记录和维护回滚日志，以及在事务失败时执行回滚操作，这会增加额外的性能开销。资源锁定时间，在事务进行期间，涉及的资源（如数据库行记录）可能会被锁定，这可能导致较长的锁定时间，影响系统的并发性能。回滚复杂性，如果事务涉及的业务逻辑非常复杂，回滚操作可能会变得复杂和困难。使用场景： CRUD密集型业务，对于增删改查操作频繁的业务场景，如电商平台的订单处理，AT模式可以有效地管理跨服务的数据一致性。微服务架构，在微服务架构中，不同的服务可能管理着不同的数据库，AT模式适用于处理跨服务的事务。简单的分布式事务， 对于业务逻辑不是特别复杂且对数据一致性要求高的分布式事务，AT模式是一个合适的选择。快速开发， 当需要快速实现分布式事务功能，而又不希望投入大量资源进行底层控制时，AT模式提供了快速的解决方案。
三，TCC模式
TCC模式将分布式事务分为两个阶段，全局事务是由若干分支事务组成，分支事务要满足两阶段提交的模型要求，即每个分支事务都具备自己的：一阶段prepare行为，二阶段commit或者rollback行为。TCC模式不依赖底层数据资源的事务支持。
1，运行原理
-
一阶段prepare行为：调用自定义的prepare行为
-
二阶段commit行为：调用自定义的commit行为
-
二阶段rollback行为：调用自定义的rollback行为
优势: TCC 完全不依赖底层数据库，能够实现跨数据库、跨应用资源管理，可以提供给业务方更细粒度的控制。缺点: TCC是一种侵入式的分布式事务解决方案，需要业务系统自行实现 Try，Confirm，Cancel 三个操作，对业务系统有着非常大的入侵性，设计相对复杂。适用场景: TCC 模式是高性能分布式事务解决方案，适用于核心系统等对性能有很高要求的场景。
四，XA模式
XA 规范是X/Open组织定义的分布式事务处理（DTP，Distributed Transaction Processing）标准。Seata XA 模式是利用事务资源（数据库、消息服务等）对 XA 协议的支持，以 XA 协议的机制来管理分支事务的一种事务模式。
1，运行原理
- 执行阶段：
- 可回滚：业务 SQL 操作放在 XA 分支中进行，由资源对 XA 协议的支持来保证可回滚
- 持久化：XA 分支完成后，执行 XA prepare，同样，由资源对 XA 协议的支持来保证 持久化（即，之后任何意外都不会造成无法回滚的情况）
- 完成阶段：
- 分支提交：执行 XA 分支的 commit
- 分支回滚：执行 XA 分支的 rollback
优势: 与Seata支持的其它事务模式不同，XA 协议要求事务资源本身提供对规范和协议的支持，所以事务资源（如数据库）可以保障从任意视角对数据的访问有效隔离，满足全局数据一致性。业务无侵入：和AT一样，XA 模式将是业务无侵入的，不给应用设计和开发带来额外负担。数据库的支持广泛：XA 协议被主流关系型数据库广泛支持，不需要额外的适配即可使用。缺点: XA prepare 后，分支事务进入阻塞阶段，收到 XA commit 或 XA rollback 前必须阻塞等待。事务资源长时间得不到释放，锁定周期长，而且在应用层上面无法干预，性能差。适用场景: 适用于想要迁移到 Seata 平台基于 XA 协议的老应用，使用 XA 模式将更平滑，还有 AT 模式未适配的数据库应用。五，Saga模式
Saga 模式是 SEATA 提供的长事务解决方案，在Saga 模式中，业务流程中每个参与者都提交本地事务，当出现某一个参与者失败则补偿前面已经成功的参与者，一阶段正向服务和二阶段补偿服务都由业务开发实现。优势：一阶段提交本地事务，无锁，高性能，事件驱动架构，参与者可异步执行，高吞吐，补偿服务易于实现缺点：不保证隔离性适用场景：业务流程长、业务流程多。参与者包含其它公司或遗留系统服务，无法提供 TCC 模式要求的三个接口。
欢迎关注微信公众号，获取小王第一手技术文章：小王聊技术
