背景
每次说起分布式事务相信都是许多开发者的心头痛，分布式事务往往伴随着大量的业务逻辑的侵入，需要写大量的回滚操作的业务流程，而且还生怕哪里漏掉了。而现在，于2019年1月10日，阿里巴巴开源了内部的分布式事务框架——Fescar。Fescar是Fast Easy Commit And Rollback的缩写。
目前业界的分布式事务分为两种，一是业务0侵入的，使用的是数据库的XA组件，但是缺陷也很明显。所用的数据库必须支持XA组件，另外这种方式锁占用时间长，需要搭配重量级的容器使用，在分布式系统场景中并不合适。二是业务侵入的，例如TCC，目前用得比较多的是这种，也有成熟的方案，只是这样需要开发大量的回滚流程，十分耗费人力物力。而Fescar就是解决了这两个问题，既能做到适配各种关系型数据库，又能业务0侵入。
阿里巴巴内部一直有在做分布式事务的探索，TXC是目前阿里巴巴内部使用的分布式框架，而GTS则是在阿里云上分布式事务，而这次开源的Fescar也是源自这两者，当然开源的是免费的，开源一个月的时间现在Github上已经有5000多颗星了，可见大家对分布式事务有多渴望。
原理
首先先说说什么是分布式事务，以电商购物为例，当消费者购买了下单一件商品时，库存系统会扣减库存，而支付系统会进行扣款，当扣款失败时，库存应该要重新回滚到原来的数量，可是在分布式系统中，系统往往不是使用同一个数据库，因此数据库没法保证本地事务外的事务，这就是分布式事务。
目前流行的TCC分成三个阶段，一是Try，尝试把资源冻结和锁住，若全部服务均成功，则执行Confirm操作，执行真实的写操作，否则执行Cancel，取消资源冻结。TCC伴随着大量的业务逻辑以及需要可靠的MQ支撑，虽然比较成熟，可是需要开发者花大量的心思去开发。
而Fescar作为业务0侵入的框架是如何实现的呢？
![image]( "image")
免费的分布式事务来了——阿里巴巴Fescar
如上图所示（图片来自Github），Fescar由RM、TM、TC组成。
RM是资源管理器，主要是做分支/本地事务的提交和回滚。
TM是事务管理器，主要是确定全局事务的开始和全局事务的提交和回滚。
TC是事务协调器，主要是当TM确定要提交或回滚时协调各个分支事务做相应的操作。
流程是这样的，还是拿回开始的那个例子，当用户下单时，TM会发起全局事务，并向TC注册一个XID作为事务的唯一标志，然后在调用库存系统扣减库存，此时库存系统的RM会向TC注册并执行本地事务，支付系统同理。当支付系统的RM执行失败时，TM会向TC发起全局事务回滚的决议，此时TC会组织两个系统的RM同时进行回滚操作，整个分布式事务完成。
特点
不依赖数据库的协议支持
Fescar的RM是处于应用层，与数据库本身的协议无关，而XA则相反，它也有类似RM的概念，可是它的RM是处于数据库层，这就意味着XA需要强依赖数据库支持XA协议，因此Fescar是非常适合弱耦合的分布式系统的。
锁的时间短
Fescar与XA同样都是两阶段提交，但是区别在于XA是两阶段均结束后才会释放锁，而Fescar若是做全局事务的提交操作则会在阶段一结束后就释放锁，只有是做回滚操作才会两阶段后才释放锁。而大部分场景都是能正常提交的，所以Fescar能保证锁的占用时间控制到最短，这也变相地提高了数据库的qps。（这里可能会有人会问阶段1结束就释放锁不会造成资源会被的事务占用吗，Fescar在这里实际上做了一个全局写操作的隔离，不会出现脏写的情况，这里不展开说）
隔离性
Fescar默认支持读未提交的隔离性，因为主要是考虑到其实大部分场景用这个隔离性就已经足够了。不过官网也支持读已提交的隔离性配置，不过就需要对业务进行侵入了，所以在选型时也要考虑业务本身的需求。
总结
总的来说Fescar是对目前分布式事务版图的一个很好的补充，而且已在阿里巴巴有长时间的成功经验，相信大多数的开发者都可以放心使用。
