Seata概念的总结

微服务与分布式事务

分布式事务是随着服务拆分而产生的问题，至于为什么要做服务拆分以及什么是微服务，可以参考下这里 我们知道对于分布式场景而言，肯定是遵循CAP理论的，所以对于这种情况下的事务而言，跨多个服务的调用事务则成了一个令人头疼的点，而Seata则是一个用于解决分布式环境下事务的框架。

Seata历史介绍

Seata是阿里开发的一个用于微服务架构的高性能易使用的分布式事务框架。 Seata由TXC（Taobao Transaction Constructor，阿里于2014开始着手解决分布式事务的内部框架）-》GTX（Global Transaction Service，阿里于2016年将TXC发布于云服务并且改名为GTX）-》Fescar（阿里于2019将GTS开源并改名为Fescar）-》Seata（Simple Extensible Autonomous Transaction Architecture，阿里将蚂蚁金服框架DTX与Fescar结合并且改名为Seata） 目前Seata已经是github上一个大热的项目，年初开源，现在发布至0.8.0版本，已经有11000的star数，并且在快速的更新迭代。 相信未来会是一个普遍的分布式事务解决方案。

Seata架构

Seata目前的事务模式有AT，TCC，Saga三种模式，默认即是AT模式，AT本质上是2pc协议的一种实现，三种模式的不同后面文章再详细介绍。 这里我们简单介绍下Seata是如何解决分布式事务的

假设我们现在有一个商品购物的业务，对于后台系统而言有四个服务，Business(业务入口)，Storage（库存服务），Order（订单服务），Account（用户服务），用户通过Business购买商品下单，在系统内部会经历以下流程：

如图所示，Business通过rpc框架（dubbo，feign....)调用其他服务。Seata将上面整个调用链所产生的事务结合生成了一个全局事务：

如图所示，对于全局事务而言，它由各个分支事务结合而成，而分支事务则代表一个服务的本地事务。

 

对于每个服务来说，代表了两种角色：

如图所示，对于每一个服务而言都有两种角色（TM，RM）,在全局事务的过程中，它们会与TC进行通信协助完成整个事务，可以简单介绍下每个角色的作用:

 

TC

： Transaction Coordinator，事务协调器：监视每个全局事务的状态，负责全局事务的提交和回滚。

 

TM

: Transaction Manager, 事务管理者：向TC

发起，提交，回滚

全局事务的请求。

 

RM

: Resource Manager, 资源管理器：服务向TC

发起，提交，报告

分支事务的请求，并且服务本地事务的回滚，提交。

 

Seata处理一个全局事务的流程如下：

1. TM向TC请求发起一个全局事务，TC返回一个代表这个全局事务的XID。

2. XID在rpc中传播给每一个调用链中的服务。

3. 每个RM拿到XID后向TC发起一个分支事务，TC返回一个代表这个分支事务的XID。

4. RM完成本地分支的业务，提交本地分支，并且报告给TC。

5. 全局事务调用链处理完毕，TM根据有无异常向TC发起全局事务的提交或者回滚。

回滚：

1. 假设某个RM本地事务失败。该RM自身驱动本地事务回滚，并且报告给TC。

2. TM检测到了某个分支事务失败，向TC发起全局事务回滚。

3. TC给每一个RM发送消息，通知它们全部回滚。

4. TC将全局事务回滚的结果发送给TM。 全局事务结束。

   

三种模式

AT模式

一阶段

在一阶段，Seata 会拦截“业务 SQL”，首先解析 SQL 语义，找到“业务 SQL”要更新的业务数据，在业务数据被更新前，将其保存成“before image”，然后执行“业务 SQL”更新业务数据，在业务数据更新之后，再将其保存成“after image”，最后生成行锁。以上操作全部在一个数据库事务内完成，这样保证了一阶段操作的原子性。

二阶段

• 提交

  二阶段如果是提交的话，因为“业务 SQL”在一阶段已经提交至数据库， 所以 Seata 框架只需将一阶段保存的快照数据和行锁删掉，完成数据清理即可。

  

• 回滚

  二阶段如果是回滚的话，Seata 就需要回滚一阶段已经执行的“业务 SQL”，还原业务数据。回滚方式便是用“before image”还原业务数据；但在还原前要首先要校验脏写，对比“数据库当前业务数据”和 “after image”，如果两份数据完全一致就说明没有脏写，可以还原业务数据，如果不一致就说明有脏写，出现脏写就需要转人工处理。

  

AT 模式的一阶段、二阶段提交和回滚均由 Seata 框架自动生成，用户只需编写“业务 SQL”，便能轻松接入分布式事务，AT 模式是一种对业务无任何侵入的分布式事务解决方案。

TCC模式

可见Tcc.md

Saga模式

Saga 理论出自 Hector & Kenneth 1987发表的论文 Sagas。 saga模式的实现，是长事务解决方案。 Saga 是一种补偿协议，在 Saga 模式下，分布式事务内有多个参与者，每一个参与者都是一个冲正补偿服务，需要用户根据业务场景实现其正向操作和逆向回滚操作。

分布式事务执行过程中，依次执行各参与者的正向操作，如果所有正向操作均执行成功，那么分布式事务提交。如果任何一个正向操作执行失败，那么分布式事务会退回去执行前面各参与者的逆向回滚操作，回滚已提交的参与者，使分布式事务回到初始状态。

Saga 正向服务与补偿服务也需要业务开发者实现。因此是业务入侵的。

Saga 模式下分布式事务通常是由事件驱动的，各个参与者之间是异步执行的，Saga 模式是一种长事务解决方案。

使用场景

Saga 模式适用于业务流程长且需要保证事务最终一致性的业务系统，Saga 模式一阶段就会提交本地事务，无锁、长流程情况下可以保证性能。

事务参与者可能是其它公司的服务或者是遗留系统的服务，无法进行改造和提供 TCC 要求的接口，可以使用 Saga 模式。

优势:

1. 一阶段提交本地数据库事务，无锁，高性能；

2. 参与者可以采用事务驱动异步执行，高吞吐；

3. 补偿服务即正向服务的“反向”，易于理解，易于实现；

缺点：Saga 模式由于一阶段已经提交本地数据库事务，且没有进行“预留”动作，所以不能保证隔离性。后续会讲到对于缺乏隔离性的应对措施。

蚂蚁金服使用经验

• 允许空补偿：原服务未执行，补偿服务执行了

  

• 防悬挂控制：允许空补偿，但要拒绝空回补偿后的原服务执行

  

• 幂等控制：原服务与补偿服务都需要保证幂等性

  

• 自定义事务恢复策略：

  

•