分布式事务处理过程的-ID+三组件模型：

关于事务的基本概念

Seata 是阿里开源的分布式事务解决方案中间件，对业务侵入小，在应用中 Seata 整体事务逻辑基于两阶段提交的模型，核心概念包含三个角色：

• TM：事务发起者。用来告诉 TC 全局事务的开始，提交，回滚。

• RM：事务资源，每一个 RM 都会作为一个分支事务注册在 TC。

• TC：事务协调者，即独立运行的 seata-server，用于接收事务注册，提交和回滚。

Seata 的运行分 AT 和 MT 两种模式。还有其他的模式如 SAGA，还未研究。

AT(Auto Transaction)模式

这个模式需要模块为 Java 语言，并且数据库支持本地事务。一个典型的分布式事务过程：

• TM 向 TC 申请开启一个全局事务，全局事务创建并生成一个全局唯一的 XID。

• XID 在微服务调用链路的上下文中传播。

• RM 向 TC 注册分支事务，将其纳入 XID 对应全局事务的管辖。

• TM 向 TC 发起针对 XID 的全局提交或回滚决议。

• TC 调度 XID 下管辖的全部分支事务完成提交或回滚请求。

MT(Manual Transaction)模式

这个模式适合其他的场景，因为底层存储可能没有事务支持，需要自己实现 prepare、commit 和 rollback 的逻辑

处理过程

为什么 Seata 在第一阶段就直接提交了分支事务？

Seata 能够在第一阶段直接提交事务，是因为 Seata 框架为每一个 RM 维护了一张 UNDO_LOG 表（这张表需要客户端自行创建），其中保存了每一次本地事务的回滚数据。因此，二阶段的回滚并不依赖于本地数据库事务的回滚，而是 RM 直接读取这张 UNDO_LOG 表，并将数据库中的数据更新为 UNDO_LOG 中存储的历史数据。

如果第二阶段是提交命令，那么 RM 事实上并不会对数据进行提交（因为一阶段已经提交了），而实发起一个异步请求删除 UNDO_LOG 中关于本事务的记录。

有些地方的官网文档写的可能比较难理解，那么接下来我会用简单的方式来描述一下如何搞定分布式事务

快速入门

譬如你有两个微服务，一个是库存模块 StorageService，一个是订单模块 OrderService，主业务是用户下单，然后需要分别调用上面的两个服务，完成减库存、用户扣款和下单操作。由于两个服务是不同的服务，并且是不同的数据库，那么这就是一个典型的分布式事务场景。我们希望要么全部成功，要么全部失败。

/** * 用户下单 */public void purchase(String userId, String commodityCode, int orderCount) {        //减库存        storageService.deduct(commodityCode, orderCount);        //扣款、生成订单        orderService.create(userId, commodityCode, orderCount);    }

复制代码

其中 OrderService 做了如下操作，扣减钱款、生成订单。库存 Service 就是减了一下库存。

那么要完成这次分布式事务，只需要在 purchase 方法上加个注解即可。看起来确实是一个注解，解决所有。

@GlobalTransactional    public void purchase(String userId, String commodityCode, int orderCount) {        ......    }

复制代码

有话说：

Springcloud Alibaba 里的 steata 分布式事务的简单讲解就是这样了，由于篇幅原因，很多朋友可能还觉得干货讲得还不够多，我手里有一份关于 SpringCloudAlibaba 笔记，里面系统的讲解了 springcloud Alibaba 的各种内容，应有尽有！

笔记内容

资料目录

Seata--分布式事务

1.分布式事务基础、2.本地事务、3.全局事务、4.最大努力通知等更多笔记内容

由于篇幅原因内容无法全部截出，可看文末获取方式。

第一章微服务介绍

随着互联网的发展，网站应用的规模不断的扩大，进而导致系统架构也在不断的进行变化。本章就讲述了每种架构系统是什么样子的，以及有什么的作用。

介绍 Spring cloud alibaba

第四章 Sentinel--服务容错篇

在微服务架构中，我们将业务拆分成一个个的服务，服务于服务之间可以互相调用，但是由于网络原因或者自身原因，服务并不能保证服务 100%可用，如果单个服务出现问题，调用整个服务就会出现网络延迟，此时若有大量网络进来，最终会导致服务瘫痪的，所以这篇便讲解了一个高并发带来的问题等。

 

总结

Seata 分布式事务只是 Springcloud Alibaba 里面的一部分，想要真正的了解它，一定要系统的了解它的整个内容。

俗话说，知己知彼百战百胜，想要克服“Seata 分布式”这一难题，先要了解 springcloud alibaba 整体的分布和内容，并抓住其关键和本质。

如果您对如何更好地系统性学习 Springcloud Alibaba 还没有好的办法，这份笔记可以很好地帮助到您！

资料已整理成文档，需要获取的小伙伴可以直接转发+关注后私信（学习）即可获取哦