本文首发于个人微信公众号《andyqian》, 期待你的关注~
前言
上一篇文章《Seata 之 rm-datasource 源码解读》发出后。有很多同学对 Seata 是什么还不够了解,今天我们就起来认识一下它。
简介
Seata 是一款由阿里巴巴与蚂蚁金服共同开源的分布式事务框架。由最初的Fescar(Fast & Easy Commit And Rollback)框架更名而来。其设计初衷是:让分布式事务能够像本地事务一样简单,高效。
什么是分布式事务?
在上面介绍中,提到了分布式事务,它并不是一个新词。但在介绍之前,我觉得有必要先回顾下。事务是我们熟悉的,它有四大特性,分别是:原子性,一致性,隔离性,持久性。由底层数据库提供支持,如MySQL中的 Innodb 存储引擎。在单体应用中,甚至是在单例数据库应用中,使用数据库本身提供的事务就能解决大部分:数据不一致等一系列问题。架构如下图所示:
随着互联网应用的发展,单体应用架构已不足以应付。且呈现出诸多弊端,例如:多团队开发效率不高,模块之间强耦合,打包部署慢,等问题。后面大家采用了分而治之的方法,就有了SOA架构,再到现在盛行的微服务架构。
当然,当单一数据库实例不足以支撑现有的业务时,就出现了分库分表。通常的做法是:将不同的业务分为不同的数据库实例。也就有了如下的分布图:
图片来自于 seata 博客
在这样的架构下。原本数据库提供的本地事务已经相形见绌,并提出了一个新的挑战。在分布式架构下,如何保证数据的一致性,原子性等等 ?
CAP 理论
在单体应用中,有数据库本身提供的事务保驾护航,我们可以更加关注的编写业务代码。在分布式应用中,在面对各个节点状态同步时,提出了一个新的理论,它就是CAP 理论。
CAP 理论最早由:加州大学的计算机科学家 Eric Brewer 在 1998 年提出,分布式系统有三个指标:
- Consistency (一致性)
- Availability (可用性)
- Partition tolerance (分区容忍性)
Eric Brewer 说,这三个指标不可能同时做到。
其架构图如下所示:
图片来自 阮一峰 博客
Seata 的原理
在 Seata中,是如何定义分布式事务的呢?从上图改造而来,如下图所示:
图片来自 seata 博客
在 Seata 中,将 Storage 服务看成一个本地事务,Business 服务看成一个本地事务,将 Order 服务看成一个本地事务,将 Account 服务看成一个本地事务,其构成了一个 Distributed Transaction,由 TC 统一协调。在 Seata 中称之为 “Global Transaction”,如下所示:
图片来自 seata 博客
在 Seata 中有三个基础组件:
- Transaction Coordinator(TC)(协调者):维护全局和分支事务的状态,驱动全局提交或回滚。
- Transaction Manager(TM)(事务管理):定义全局事务的范围,开启全局事务,提交 或 回滚一个全局事务。
- Resource Manager(RM)(资源管理):管理分支事务资源。与 TC 通讯并报告分支事务状态,管理本地事务的提交与回滚。
Seata 的生命周期
在 Seata 中,一个典型的生命周期如下所示:
- TM 要求 TC 生成一个全局事务,并由 TC 生成一个全局事务XID 返回。
- XID 通过微服务调用链传播。
- RM 向 TC 注册本地事务,将其注册到 ID 为 XID 的全局事务中。
- TM 要求 TC 提交或回滚XID 对应的全局事务。
- TC 驱动 XID 对应的全局事务对应的所有的分支事务提交或回滚。
图片来自seata 博客
相关阅读:
《Dubbo 线程池源码解析》
《你所不知道的 BigDecimal》
《ThreadPoolExecutor 原理解析》
《Java线程池ThreadPoolExecutor》
扫码关注,一起进步
个人博客: http://www.andyqian.com