分布式事务中间件 Fescar—RM 模块源码解读
前言
在SOA、微服务架构流行的年代,许多复杂业务上需要支持多资源占用场景,而在分布式系统中因为某个资源不足而导致其它资源占用回滚的系统设计一直是个难点。我所在的团队也遇到了这个问题,为解决这个问题上,团队采用的是阿里开源的分布式中间件Fescar的解决方案,并详细了解了Fescar内部的工作原理,解决在使用Fescar中间件过程中的一些疑虑的地方,也为后续团队在继续使用该中间件奠定理论基础。
阿里开源分布式事务解决方案 Fescar 全解析
广为人知的阿里分布式事务解决方案:GTS(Global Transaction Service),已正式推出开源版本,取名为“Fescar”,希望帮助业界解决微服务架构下的分布式事务问题,今天我们一起来深入了解。
微服务架构下,解决数据一致性问题的实践
随着业务的快速发展,应用单体架构暴露出代码可维护性差、容错率低、测试难度大和敏捷交付能力差等诸多问题,微服务应运而生。微服务的诞生一方面解决了上述问题,但是另一方面却引入新的问题,其中主要问题之一就是:如何保证微服务间的业务数据一致性。
阿里分布式事务框架GTS开源啦!
就在9号这天,阿里分布式事务框架GTS开源了一个免费社区版Fescar,看到了这个消息内心非常的激动!在微服务系统中,分布式事务一直是痛点,也是难点。社区里也有一些开源的分布式解决方案的框架,比如ByteTCC、LCN,但是这些框架没有一个权威的组织在维护,或多或少大家都有点不敢用。
分布式事务中间件 Fescar - 全局写排它锁解读
前言
一般,数据库事务的隔离级别会被设置成 读已提交,已满足业务需求,这样对应在Fescar中的分支(本地)事务的隔离级别就是 读已提交,那么Fescar中对于全局事务的隔离级别又是什么呢?如果认真阅读了 分布式事务中间件Txc/Fescar-RM模块源码解读 的同学应该能推断出来:Fescar将全局事务的默认隔离定义成读未提交。
Fescar example解析 - TM流程
背景
Fescar 是 阿里巴巴 开源的 分布式事务中间件,以 高效 并且对业务0侵入的方式,解决微服务场景下面临的分布式事务问题,介绍可以参考Fescar介绍。
Fescar example解析系列主要是通过阅读Fescar的example源码梳理Fescar的整体逻辑,偏重于整体流程的梳理,让大家在整体上能够有一个宏观了解。
Fescar&Seata分布式事务实现原理解析探秘
前言
fescar发布已有时日,分布式事务一直是业界备受关注的领域,fescar发布一个月左右便受到了近5000个star足以说明其热度。当然,在fescar出来之前,已经有比较成熟的分布式事务的解决方案开源了,比较典型的方案如LCN(https://github.com/codingapi/tx-lcn)的2pc型无侵入事务,目前lcn已发展到5.0,已支持和fescar事务模型类似的TCX型事务。
Fescar example解析 - GlobalTransaction
开篇
这篇文章是接着Fescar example解析 - TM流程的下一步分析,主要是对TM的处理逻辑的进一步分析,理清楚TM(Transaction Manager )的处理步骤以及代码调用链。
这篇文章的结论是TM执行事务操作包括begin/commit/rollback都是通过DefaultTransactionManager类来实现,实现形式是TM和TC进行网络通信,在整个TM->TC的过程中TM担当了Client端的角色,TC担当了Server端的角色。
Fescar 全局锁介绍
开篇
这篇文章的目的主要是讲解TC的在处理分支事务注册过程中对全局锁的处理流程,理解了全局锁以后才能明白对DB同一个记录进行多次变更是如何解决的。
如上图所示,问最终全局事务A对资源R1应该回滚到哪种状态?很明显,如果再根据UndoLog去做回滚,就会发生严重问题:覆盖了全局事务B对资源R1的变更。
蚂蚁金服分布式事务开源以及实践 | SOFA 开源一周年献礼
上周,分布式事务 Fescar 宣布进行品牌升级为 Seata,蚂蚁金服在 Seata 0.4.0 版本加入了 TCC 模式,后续也会持续输入。本文根据 SOFAMeetup 北京站现场分享整理详细,讲述了分布式事务在蚂蚁金服的发展以及开源版本的规划,希望可以帮助大家理解。