谈谈分布式事务

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

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

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

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

比如说金融行业，转账数据搞错了，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年多，对分布式系统下数据一致性问题有深入理解，有兴趣的朋友欢迎交流哈。