谈谈分布式事务

对于分布式事务，用户本质诉求是什么？

分布式事务解决的用户最本质诉求是什么？数据一致。

大中企业有一个共同的诉求是数据一致，几乎覆盖到各个行业。

好比说零售行业，库存与出货的数据须要保持一致，出货量与库存数据不匹配，显而易见会出问题，拿到订单却没货了，或者有货却下不了订单。

好比说金融行业，转帐数据搞错了，A扣款了，B没加上，立刻该用户投诉了；A没扣款，B却加上了，产生资损。又好比从总帐户中买了基金、股票后余额不对了，等等，都会致使严重问题。

之前多数企业的数据规模相对较小，不少操做是单机完成，数据库本地事务能够搞定，因此数据一致问题不那么明显。

随着互联网技术快速发展，数据规模增大，分布式系统愈来愈普及，采用分布式数据库或者跨多个数据库的应用在中大规模企业广泛存在，服务化也是普遍应用，因为网络的不可靠和机器不可靠，数据不一致问题很容易出现。

数据一致问题的现有解决方案
数据一致问题是必须解决的，在不少大企业多年前就已经成为突出问题，他们是怎么解决的？有这么几个典型方案：

* a）XA事务方案
* b）柔性事务
* c）基于消息的最终一致
* d）人工订正

方案a，XA协议由Tuxedo首先提出的，并交给X/Open组织，做为资源管理器（数据库）与事务管理器的接口标准。Oracle、Informix、DB2和Sybase等各大数据库厂家都提供对XA的支持。XA协议采用两阶段提交方式来管理分布式事务。最主要缺点是性能差，容易成为业务发展瓶颈，因此国内不多用户采用。

方案b，柔性事务（遵循BASE理论）是指相对于ACID刚性事务而言的，常见的是TCC型事务（Try/Confirm/Cancel）。最主要缺点是业务侵入性太强，须要大量开发工做进行业务改造，给业务升级、运维都带来困难。只适合特定领域，不可能做为通用方案对外大面积铺开。

方案c，经常使用办法是经过本地消息表完成，也有一些经过事务消息。主要缺点一样是业务侵入强，须要大量额外开发工做，给业务升级、运维都带来困难。还有一个问题是使用场景受限，有些最终一致没法知足的状况，须要人工干预。优势是扩展性好，能够知足日益扩大的业务。

方案d，多数中小企业靠人工订正解决。缺点是运维、支持投入人力大。在业务不是很复杂的状况下能hold住，但业务扩大了就很难应付了。

这些问题很明显，为何没有产品解决？由于技术层面很难，缺少关键创新，这已是至少10多年的世界性难题了。这种状况下，GTS横空出世，经过一系列技术创新，但愿能完全解决这些问题。

GTS解决数据一致问题
从上面分析能够看出，方案b/c/d是由于a的性能知足不了业务需求的无奈之举。

作出一个一样知足事务ACID的强一致的通用分布式事务中间件，而且性能足够，简单易用，才是终极方案，这就是GTS的出发点。

事务比较抽象，我举个例子类比下GTS给用户带来了哪些改变。

你天天上班，要通过一条10千米的只有两条车道的马路到达公司。这条路很堵，常常须要两三个小时，上班时间没有保证，这是方案a的问题。

选择一条很绕，长30千米但不多堵车的路，这是选b。上班时间有保证，可是必须早起，付出足够的时间和汽油。

选择一条有点绕，长20千米的山路，路不平，只有suv能够走，这是选c。上面分析了c方案场景受限，对应于交通，是底盘低的小轿车无法开。好处是，你买了suv走这条山路，时间不算太长（相比b），能够保证按时上班。

发扬艰苦奋斗，走路上班，这是选d。

显然，各类方案都不完美。为了完美解决这些问题，阿里巴巴推出了分布式事务产品GTS （https://www.aliyun.com/aliware/txc ）

GTS作的是什么？修了一条拥有4条车道的高架桥，没有绕路，仍是10千米。
不堵车，对事务来讲是高性能；不绕路，对事务来讲是简单易用，不用为事务而额外编码；没有车辆类型限制，对事务来讲是没有功能限制，提供强一致事务。
在没有高架桥的时代，高架桥出现对交通来讲就是一个颠覆性创新，不少之前看来无解的问题就迎刃而解了，一样的，GTS经过创新，但愿能够改变数据一致性处理的行业现状。

经过这个类比，但愿能够体会到GTS给用户带来了哪些价值。

GTS已经普遍应用于阿里内部应用，大量重量级专有云用户和公有云用户，并获得用户高度评价 （https://www.aliyun.com/aliware/hotproducts/gtscase1）

本人是阿里巴巴GTS产品创始人（姜宇，花名于皋），在分布式事务领域作了9年多，对分布式系统下数据一致性问题有深刻理解，有兴趣的朋友欢迎交流哈。