网上关于散布式事务讲实际的多，讲实战的少，明天我想经过一个案例，来让小同伴们感受一把散布式事务，我们明天尽量少谈点实际。我们明天的主角是 Seata！
散布式事务触及到很多实际，如 CAP，BASE 等，很多小同伴刚看到这些实际就被劝退了，所以我们明天不讲实际，我们就看个 Demo，经过代码快速体验一把什么是散布式事务。
1. 什么是 Seata？Seata 是一款开源的散布式事务处置方案，努力于提供高功用和复杂易用的散布式事务效劳。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务形式，为用户打造一站式的散布式处置方案。
Seata 支持的事务形式有四种辨别是:
Seata AT 形式
Seata TCC 形式
Seata Saga 形式
Seata XA 形式
Seata 中有三个中心概念：
TC (Transaction Coordinator) - 事务协调者：维护全局和分支事务的形状，驱动全局事务提交或回滚。
TM (Transaction Manager) - 事务管理器：定义全局事务的范围，末尾全局事务、提交或回滚全局事务。
RM ( Resource Manager ) - 资源管理器：管理分支事务处置的资源( Resource )，与 TC 交谈以注册分支事务和报告分支事务的形状，并驱动分支事务提交或回滚。
其中，TC 为独自部署的 Server 效劳端，TM 和 RM 为嵌入到运用中的 Client 客户端。
这些概念小同伴们作为一个了解即可，不了解也能用 Seata，了解了更能了解 Seata 的任务原理。
2. 搭建 Seata 效劳端我们先来把 Seata 效劳端搭建起来。
Seata 下载地址：
https://github.com/seata/seata/releases
目前最新版本是 1.4.2，我们就运用最新版本来做。
这个工具在 Windows 或许 Linux 上部署差别不大，所以我这里就直接部署在 Windows 上了，方便一些。
我们首先下载 1.4.2 版本的 zip 紧缩包，下载之后解压，然后在 conf 目录中配置两个中央：
1. 首先配置 file.conf 文件
file.conf 中配置 TC 的存储形式，TC 的存储形式有三种：
file：适宜单机形式，全局事务会话信息在内存中读写，并耐久化本地文件 root.data，功用较高。
db：适宜集群形式，全局事务会话信息经过 db 共享，相对功用差点。
redis：适宜集群形式，全局事务会话信息经过 redis 共享，相对功用好点，但是要留意，redis 形式在 Seata-Server 1.3 及以上版本支持，功用较高，不过存在事务信息丧失的风险，所以需求开发者提早配置适宜以后场景的 redis 耐久化配置。
这里我们为了省事，配置为 file 形式，这样事务会话信息读写在内存中完成，耐久化则写到本地 file，如下图：
假设配置 db 或许 redis 形式，大家记得填一下下面的相关信息。详细如下图：
另外还需求留意的是本人的数据库版本信息，改数据库衔接的时分按照实践状况修正，Seata 针对 MySQL5.x 和 MySQL8.x 都提供了对应的数据库驱动（在 lib 目录下），我们只需求把驱动改好就行了。
2. 再配置 registry.conf 文件
registry.conf 主要配置 Seata 的注册中心，我们这里采用大家比较熟习的 Eureka，配置如下：
可以看到，支持的配置中心比较多，我们选择 Eureka，选好配置中心之后，记得修正配置中心相关的信息。
OK，如今就配置完成了，但是先别启动，还差一个 Eureka 注册中心。
3. 项目配置接上去我们配置项目。
Seata 官方提供了一个十分经典的 Demo，我们直接来看这个 Demo。
官方案例下载地址：https://github.com/seata/seata-samples
不过这里是很多案例混在一同的，能够看起来会比较乱，而且由于要下载的依赖比较多，所以极有能够依赖下载失败，因此大家也可以在群众号后台回复 seata-demo 获取松哥整理好的案例，直接导入即可，如下图：
这是一个商品下单的案例，我来和大家稍微解释下：
eureka：这是效劳注册中心。
account：这是账户效劳，可以查询/修正用户的账户信息（主要是账户余额）。
order：这是订单效劳，可以下订单。
storage：这是一个仓储效劳，可以查询/修正商品的库存数量。
bussiness：这是业务，用户下单操作将在这里完成。
这个案例讲了一个什么事呢？
当用户想要下单的时分，调用了 bussiness 中的接口，bussiness 中的接口又调用了它本人的 service，在 service 中，首先开启了全局散布式事务，然后经过 feign 调用 storage 中的接口去扣库存，然后再经过 feign 调用 order 中的接口去创立订单（order 在创立订单的时分，不只会创立订单，还会扣除用户账户的余额），在扣除库存并完成订单创立之后，接上去会去反省用户的余额和库存数量能否正确，假设用户余额为正数或许库存数量为正数，则会停止事务回滚，否则提交事务。本案例详细架构如下图：
这个案例就是一个典型的散布式事务成绩，storage 和 order 中的事务分属于不同的微效劳，但是我们希望他们同时成功或许同时失败。
如今大家明白了这个案例是干嘛的，我们就来把它跑起来。
首先创立一个名为 seata 的数据库，然后执行下面代码中的 all.sql 数据脚本。
接上去用 idea 翻开下面这个项目，在每一个项目的 application.properties 文件中（Eureka 不用改），修正数据的衔接信息，如下图：
(责任编辑：admin)