阿里分布式事务框架GTS开源啦！
就在9号这天，阿里分布式事务框架GTS开源了一个免费社区版Fescar，看到了这个消息内心非常的激动！在微服务系统中，分布式事务一直是痛点，也是难点。社区里也有一些开源的分布式解决方案的框架，比如ByteTCC、LCN，但是这些框架没有一个权威的组织在维护，或多或少大家都有点不敢用。
分布式事务中间件 Fescar - 全局写排它锁解读
前言
一般，数据库事务的隔离级别会被设置成 读已提交，已满足业务需求，这样对应在Fescar中的分支（本地）事务的隔离级别就是 读已提交，那么Fescar中对于全局事务的隔离级别又是什么呢？如果认真阅读了 分布式事务中间件Txc/Fescar-RM模块源码解读 的同学应该能推断出来：Fescar将全局事务的默认隔离定义成读未提交。
免费的分布式事务来了——阿里巴巴Fescar
背景
每次说起分布式事务相信都是许多开发者的心头痛，分布式事务往往伴随着大量的业务逻辑的侵入，需要写大量的回滚操作的业务流程，而且还生怕哪里漏掉了。而现在，于2019年1月10日，阿里巴巴开源了内部的分布式事务框架——Fescar。
Fescar example解析 - GlobalTransaction
开篇
这篇文章是接着Fescar example解析 - TM流程的下一步分析，主要是对TM的处理逻辑的进一步分析，理清楚TM(Transaction Manager )的处理步骤以及代码调用链。
这篇文章的结论是TM执行事务操作包括begin/commit/rollback都是通过DefaultTransactionManager类来实现，实现形式是TM和TC进行网络通信，在整个TM->TC的过程中TM担当了Client端的角色，TC担当了Server端的角色。
Fescar example解析 - TC流程
开篇
这篇文章主要是梳理TC处理TM发送消息的过程，由于消息种类较多所以打算额外写篇文章分析，这篇文章主要把进入网络层以后的基本流程梳理下，方便大家阅读源码。
这篇文章的没有针对TM的接收部分进行分析，针对收到报文以后的处理流程。
Fescar 全局锁介绍
开篇
这篇文章的目的主要是讲解TC的在处理分支事务注册过程中对全局锁的处理流程，理解了全局锁以后才能明白对DB同一个记录进行多次变更是如何解决的。
如上图所示，问最终全局事务A对资源R1应该回滚到哪种状态？很明显，如果再根据UndoLog去做回滚，就会发生严重问题：覆盖了全局事务B对资源R1的变更。
