分布式事务 Seata

简介

Seata(Simple Extensible Autonomous Transaction Architecture) 是 阿里巴巴开源的分布式事务中间件，以高效并且对业务 0 侵入的方式，解决微服务场景下面临的分布式事务问题。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。
事务(Transaction)是访问并可能更新数据库中各种数据项的一个程序执行单元(unit)。在关系数据库中，一个事务由 一组SQL语句组成。事务应该具有4个属性：原子性、一致性、隔离性、持久性。这四个属性通常称为ACID特性。
原子性（atomicity）：个事务是一个不可分割的工作单位，事务中包括的诸操作要么都做，要么都不做。 
一致性（consistency）：事务必须是使数据库从一个一致性状态变到另一个一致性状态，事务的中间状态不能被观 察到的。 
隔离性（isolation）：一个事务的执行不能被其他事务干扰。即一个事务内部的操作及使用的数据对并发的其他事务 是隔离的，并发执行的各个事务之间不能互相干扰。隔离性又分为四个级别：读未提交(read uncommitted)、读已提交 (read committed，解决脏读)、可重复读(repeatable read，解决虚读)、串行化(serializable，解决幻读)。 
持久性（durability）：持久性也称永久性（permanence），指一个事务一旦提交，它对数据库中数据的改变就应该 是永久性的。接下来的其他操作或故障不应该对其有任何影响。 任何事务机制在实现时，都应该考虑事务的ACID特性，包括：本地事务、分布式事务，及时不能都很好的满足，也要 考虑支持到什么程度。

分布式事务场景

1.跨库事务，一个应用某个功能需要操作多个库，不同的库中存储不同的业务数据。
2.分库分表
3.微服务项目，不同项目调用不同的库

Seata的三大角色

在 Seata 的架构中，一共有三个角色：
TC (Transaction Coordinator) - 事务协调者 维护全局和分支事务的状态，驱动全局事务提交或回滚。 
TM (Transaction Manager) - 事务管理器 定义全局事务的范围：开始全局事务、提交或回滚全局事务。 
RM (Resource Manager) - 资源管理器 管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。 
其中，TC 为单独部署的 Server 服务端，TM 和 RM 为嵌入到应用中的 Client 客户端。
在 Seata 中，一个分布式事务的生命周期如下：
1.TM 请求 TC 开启一个全局事务。TC 会生成一个 XID 作为该全局事务的编号。XID，会在微服务的调用链路中传播，保证将多个微服务 的子事务关联在一起。 
2.RM 请求 TC 将本地事务注册为全局事务的分支事务，通过全局事务的 XID 进行关联。 
3.TM 请求 TC 告诉 XID 对应的全局事务是进行提交还是回滚。 
4.TC 驱动 RM 们将 XID 对应的自己的本地事务进行提交还是回滚。

AT模式

AT模式的核心是对业务无侵入，是一种改进后的两阶段提交,
第一阶段业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。核心在于对业务sql进行解析，转换成undolog，并同时 入库.
第二阶段分布式事务操作成功，则TC通知RM异步删除undolog,分布式事务操作失败，TM向TC发送回滚请求，RM 收到协调器TC发来的回滚请求，通过 XID 和 Branch ID 找到相应的回滚日志记 录，通过回滚记录生成反向的更新 SQL 并执行，以完成分支的回滚

通过一张undo_log表来记录回滚日志信息，在执行更新的sql语句之前，先通过这个sql语句生产一条查询语句，查询出前镜像，再执行更新的sql，执行完之后，通过前镜像的id查询出后镜像，把前后镜像加上业务逻辑的sql生产一条回滚日志信息的记录，插入到回滚日志信息表。将来需要回滚数据，就是通过这张表的数据来进行回滚，通过这个回滚日志信息，生产一个update语句，把数据更新回来，这样就完成了回滚的操作。 回滚的方式是反向补偿。

XA模式

第一阶段：事务发起者TM向TC申请开启全局事务，被调用的各个服务即RM向TC注册各自的本地事务。RM执行完本地事务但还不真正提交，会向TC报告执行状态。

第二阶段：如果各个本地事务都执行成功，则TC向各个RM发送提交的指令，各个本地事务真正提交。如果有本地事务执行不成功，则TC会向各个已经执行的RM发送回退的指令。
seata中实现XA模式非常简单，同AT模式一样也是无代码入侵的，甚至用法都是一样：在调用方法上加入@GlobalTransactional注解即可,唯一要调整的是将数据源代理修改为XA模式：

TCC模式

初步操作 Try：完成所有业务检查，预留必须的业务资源。
确认操作 Confirm：真正执行的业务逻辑，不做任何业务检查，只使用 Try 阶段预留的业务资源。因此，只要 Try 操作成功，Confirm 必须能成功。另外，Confirm 操作需满足幂等性，保证一笔分布式事务能且只能成功一次。
取消操作 Cancel：释放 Try 阶段预留的业务资源。同样的，Cancel 操作也需要满足幂等性。