Seata全称是Simple Extensible Autonomous Transaction Architecture，是由阿里巴巴开源的具有高性能和易用性的分布式事务解决方案。
微服务中的分布式事务问题
我们的电商系统使用的是微服务架构，由仓储服务、订单服务、账户服务组成，三个服务分别有着自己的本地数据源。开始事务后，每个服务本身能保证数据一致性，但是服务之间将无法保证数据一致性。这也许是很多企业遇到的问题，而Seata就是解决此类问题的。
Seata组织结构
-
事务协调器（TC）：维护全局和分支事务的状态，驱动全局提交或回滚。
-
事务管理器（TM）：定义全局事务的范围：开始全局事务、提交或回滚全局事务。
-
资源管理器（RM）：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。
Seata管理的分布式事务的典型生命周期
-
TM要求TC开始新的全局事务。TC生成代表全局事务的XID。
-
XID通过微服务的调用链传播。
-
RM将本地事务注册为XID到TC的相应全局事务的分支。
-
TM请求TC提交或回滚XID的相应全局事务。
-
TC驱动XID对应全局事务下的所有分支事务，完成分支提交或回滚。
Seata AT 模式
写隔离
- 一阶段本地事务提交前，需要确保先拿到全局锁 。
- 拿不到全局锁不能提交本地事务。
- 拿全局锁的尝试被限制在一定范围内，超出范围将放弃，并回滚本地事务，释放本地锁。
举例说明：
两个全局事务 tx1 和 tx2，分别对 a 表的 m 字段进行更新操作，m 的初始值 1000。
tx1 先开始，开启本地事务，拿到本地锁，更新操作 m = 1000 - 100 = 900。本地事务提交前，先拿到该记录的 全局锁 ，本地提交释放本地锁。 tx2 后开始，开启本地事务，拿到本地锁，更新操作 m = 900 - 100 = 800。本地事务提交前，尝试拿该记录的 全局锁 ，tx1 全局提交前，该记录的全局锁被 tx1 持有，tx2 需要重试等待 全局锁 。
tx1 二阶段全局提交，释放 全局锁 。tx2 拿到 全局锁 提交本地事务。
读隔离
Seata（AT 模式）的默认全局隔离级别是读未提交，必须将其全局隔离级别修改为读已提交。
SEATA Saga 模式
Saga模式是SEATA提供的长事务解决方案，在Saga模式中，业务流程中每个参与者都提交本地事务，当出现某一个参与者失败则补偿前面已经成功的参与者，一阶段正向服务和二阶段补偿服务都由业务开发实现。
目前SEATA提供的Saga模式是基于状态机引擎来实现的，机制是：
- 通过状态图来定义服务调用的流程并生成 json 状态语言定义文件
- 状态图中一个节点可以是调用一个服务，节点可以配置它的补偿节点
- 状态图 json 由状态机引擎驱动执行，当出现异常时状态引擎反向执行已成功节点对应的补偿节点将事务回滚 注意:异常发生时是否进行补偿也可由用户自定义决定
- 可以实现服务编排需求，支持单项选择、并发、子流程、参数转换、参数映射、服务执行状态判断、异常捕获等功能