分布式事务之Seata(Fescar)

1.背景

Seata是阿里开源的一款高性能分布式事务解决方案，在2019年1月初阿里分布式事务框架GTS开源了一个免费社区版Fescar，也就是说在阿里内部叫GTS，后面开源版本叫Fescar，后面再改名为Seata，GitHub地址：https://github.com/seata/seata

2.事务

我的理解是，一次操作(不管几次远程调用)，要么一起成功，要么失败。
说到事务就不得不说数据库事务中的四大特性 ACID：

• A：原子性(Atomicity)，一个事务中的所有操作，要么全部完成，要么全部不完成，不会结束在中间某个环节。
• C：一致性(Consistency)，如果事务成功地完成，那么系统中所有变化将正确地应用，系统处于有效状态。
• I：隔离性(Isolation)，指的是在并发环境中，当不同的事务同时操纵相同的数据时，每个事务都有各自的完整数据空间。
• 持久性(Durability)，指的是只要事务成功结束，它对数据库所做的更新就必须永久保存下来。即使发生系统崩溃，重新启动数据库系统后，数据库还能恢复到事务成功结束时的状态。

数据库是怎么实现ACID的呢？通过日志，所有操作都先有redo日志，然后才开始真正操作数据库，当出现断电、异常、重启数据库时，数据库会根据当前数据的情况进行undo回滚或者是redo前滚

3.单体应用

单体应用，即使有3个模块（Storage、Order、Account），但只有一个数据源，本地事务很自然就可以保证数据一致性

4.微服务应用

但在微服务架构中就不这么简单了，这 3 个模块被设计为 3 独立的服务，每个服务有自己独立的数据库。

一次调用会跨多个进程，如果某个调用失败，那么就会导致数据不一致，怎么解决。
Seata就是用来解决微服务环境下的分布式事务解决方案

5.Seata

Seata有3个角色，TC、TM、RM

• TC：Transaction Coordinator，维护全局和分支事务的状态，驱动全局事务提交与回滚。
• TM：Transaction Manage，定义全局事务的范围：开始、提交或回滚全局事务。
• RM：Resource Manager，管理分支事务处理的资源，与 TC通信以注册分支事务并报告分支事务的状态，并驱动分支事务提交或回滚。

对上图的调用情况做一个梳理，上图 Business 开始发起事务，调用Storage，Order，此时Storage与Order会先加入TC，然后执行操作，Order再调用Account，Account也加入TC，如果调用成功则TC提交全局事务，如果中间发生错误或异常，则TC会全局回滚，怎么回滚，在开启事务后，每一次的Sql操作，Seata都会把执行的sql记录到它自己的undo_log表，也就是说，每个模块的数据库都需要创建undo_log表

需要注意的是TC是一个单独的服务程序，（Fescar-Server），需要下载、启动，地址：https://github.com/seata/seata/releases

FESCAR 管理分布式事务的典型生命周期：

• TM 要求 TC 开始新的全局事务，TC 生成表示全局事务的 XID。
• XID 通过微服务的调用链传播。
• RM 将本地事务注册到TC，加入 XID 的相应全局事务的分支。
• TM 要求 TC 提交或回滚 XID 的相应全局事务。
• TC 驱动 XID 的相应全局事务下的所有分支事务，完成分支提交或回滚。

6.代码实操

seata最开是提供的是基于Dubbo的分布式事务解决方案，后面陆续更新springboot，springcloud的解决方案，更新频繁，到现在已经是0.4.2版本
server下载地址：https://github.com/seata/seata/releases
官方提供的示例：https://github.com/fescar-group/fescar-samples
我用的是SpringCloud，那么把 springcloud-jpa-seata里的代码全部下载下来，再按照操作步骤一步步实现

拉取代码，按照上面操作，修改源码中的数据库连接地址等，启动order-service、storage-service、account-service出现启动不了的情况，控制台打印能启动，但是无法访问，后面找到问题是引入的mysql-connector-java的版本太高，从8.0.11改为5.1.47，然后按照上面的验证成功

7.后续版本发布情况

• 0.6版本支持集群，fescar-server（TC）服务端现在还是单机版，无法高可用
• 1.0版本将在2019年6月发布