Seata 分布式事务

本文首发于个人微信公众号《andyqian》， 期待你的关注~

前言

上一篇文章《Seata 之 rm-datasource 源码解读》发出后。有很多同学对 Seata 是什么还不够了解，今天我们就起来认识一下它。

简介

Seata 是一款由阿里巴巴与蚂蚁金服共同开源的分布式事务框架。由最初的Fescar（Fast & Easy Commit And Rollback）框架更名而来。其设计初衷是：让分布式事务能够像本地事务一样简单，高效。

什么是分布式事务？

在上面介绍中，提到了分布式事务，它并不是一个新词。但在介绍之前，我觉得有必要先回顾下。事务是我们熟悉的，它有四大特性，分别是：原子性，一致性，隔离性，持久性。由底层数据库提供支持，如MySQL中的 Innodb 存储引擎。在单体应用中，甚至是在单例数据库应用中，使用数据库本身提供的事务就能解决大部分：数据不一致等一系列问题。架构如下图所示：

图片来自 seata 博客

 

随着互联网应用的发展，单体应用架构已不足以应付。且呈现出诸多弊端，例如：多团队开发效率不高，模块之间强耦合，打包部署慢，等问题。后面大家采用了分而治之的方法，就有了SOA架构，再到现在盛行的微服务架构。

当然，当单一数据库实例不足以支撑现有的业务时，就出现了分库分表。通常的做法是：将不同的业务分为不同的数据库实例。也就有了如下的分布图：

图片来自于 seata 博客

 

在这样的架构下。原本数据库提供的本地事务已经相形见绌，并提出了一个新的挑战。在分布式架构下，如何保证数据的一致性，原子性等等 ？

CAP 理论
在单体应用中，有数据库本身提供的事务保驾护航，我们可以更加关注的编写业务代码。在分布式应用中，在面对各个节点状态同步时，提出了一个新的理论，它就是CAP 理论。
CAP 理论最早由：加州大学的计算机科学家 Eric Brewer 在 1998 年提出，分布式系统有三个指标：

• Consistency (一致性)
• Availability (可用性)
• Partition tolerance (分区容忍性)

Eric Brewer 说，这三个指标不可能同时做到。
其架构图如下所示：

图片来自 阮一峰 博客

 

Seata 的原理

在 Seata中，是如何定义分布式事务的呢？从上图改造而来，如下图所示：

图片来自seata 博客

图片来自 seata 博客

在 Seata 中，将 Storage 服务看成一个本地事务，Business 服务看成一个本地事务，将 Order 服务看成一个本地事务，将 Account 服务看成一个本地事务，其构成了一个 Distributed Transaction，由 TC 统一协调。在 Seata 中称之为 “Global Transaction”，如下所示：

图片来自seata 博客

图片来自 seata 博客

在 Seata 中有三个基础组件：

• Transaction Coordinator(TC)(协调者)：维护全局和分支事务的状态，驱动全局提交或回滚。
• Transaction Manager(TM)(事务管理)：定义全局事务的范围，开启全局事务，提交 或 回滚一个全局事务。
• Resource Manager(RM)(资源管理)：管理分支事务资源。与 TC 通讯并报告分支事务状态，管理本地事务的提交与回滚。

Seata 的生命周期

在 Seata 中，一个典型的生命周期如下所示：

1. TM 要求 TC 生成一个全局事务，并由 TC 生成一个全局事务XID 返回。
2. XID 通过微服务调用链传播。
3. RM 向 TC 注册本地事务，将其注册到 ID 为 XID 的全局事务中。
4. TM 要求 TC 提交或回滚XID 对应的全局事务。
5. TC 驱动 XID 对应的全局事务对应的所有的分支事务提交或回滚。

图片来自seata 博客

 

---

相关阅读:

《Dubbo 线程池源码解析》
《你所不知道的 BigDecimal》
《ThreadPoolExecutor 原理解析》
《Java线程池ThreadPoolExecutor》