阿里云如今已经提供云上统一的分布式事务解决方案，相对于咱们之前本身尝试去经过消息结合最终一致性去解决这个问题，这样统一的解决方案仍然值得借鉴和尝试。我以为若是系统上了阿里云，能够选择这套框架来使用，对中小企业是一种解放，将更多的精力放到业务中去。现把相关的介绍转载记录以下：sql
全局事务服务GTS上个月开始在阿里云上公测，上周咱们也发表了一篇「破解世界性技术难题！GTS让分布式事务简单高效」的文章，引发了业界普遍关注，接受了大量的咨询，故但愿经过本文让你们对GTS有更深刻的理解。数据库
GTS在目前在阿里内外部已经有较大规模的应用，有100多个用户，其中专有云大用户就有10多个，预计今年将有更大规模的市场需求爆发。安全
分布式事务解决的用户最本质诉求是什么？数据一致。网络
大中企业有一个共同的诉求是数据一致，几乎覆盖到各个行业。并发
好比说零售行业，库存与出货的数据须要保持一致，出货量与库存数据不匹配，显而易见会出问题，拿到订单却没货了，或者有货却下不了订单。oracle
好比说金融行业，转帐数据搞错了，A扣款了，B没加上，立刻该用户投诉了；A没扣款，B却加上了，产生资损；又好比从总帐户中买了基金、股票后余额不对了，等等，都会致使严重问题。框架
好比说车票购票网，用户退票了，可是他买的那个座位状态仍是“已售卖”，形成损失；用户购买了，却已经没座了，更是大问题。运维
数据一致对各个行业都很重要，但为何之前不觉着是个广泛需求？分布式
之前多数企业的数据规模、业务复杂度相对较小，不少操做能够单机完成，数据库本地事务能够搞定，因此数据一致问题不那么明显。工具
随着互联网技术快速发展，数据规模增大，分布式系统愈来愈普及，采用分布式数据库或者跨多个数据库的应用在中大规模企业广泛存在，服务化也是普遍应用，因为网络的不可靠和机器不可靠，数据不一致问题很容易出现。
数据一致性问题是必须解决的，在不少大企业多年前就已经成为突出问题，他们是怎么解决的？有这么几个典型方案：
• a）XA事务方案
• b）柔性事务
• c）基于消息的最终一致
• d）业务补偿与人工订正
方案a，XA协议由Tuxedo首先提出的，并交给X/Open组织，做为资源管理器（数据库）与事务管理器的接口标准。Oracle、Informix、DB2和Sybase等各大数据库厂家都提供对XA的支持。XA协议采用两阶段提交方式来管理分布式事务。最主要缺点是性能差，容易成为业务发展瓶颈，因此国内不多用户采用。优势是知足事务ACID，有几个很成熟的产品，比较稳定，典型的是Oracle Tuxedo 和 IBM CICS。可是前景不看好，这么多年缺少重要技术突破，性能上不去，怎么拥抱互联网。
方案b，柔性事务（遵循BASE理论）是指相对于ACID刚性事务而言的，常见的是TCC型事务（Try/Confirm/Cancel）。最主要缺点是业务侵入性太强，须要大量开发工做进行业务改造，给业务升级、运维都带来困难。优势是业务开发人员能够灵活控制事务逻辑，达到很好性能。在蚂蚁金服有普遍使用。以个人理解，这适合特定领域，很难做为通用方案对外大面积铺开。
方案c，经常使用办法是经过本地消息表完成，也有一些经过事务消息。主要缺点一样是业务侵入强，须要大量额外开发工做，给业务升级、运维都带来困难。还有一个问题是使用场景受限，有些最终一致没法知足的状况，须要人工干预。优势是扩展性好，能够知足日益扩大的业务，相对b来讲开发没那么复杂。这是比较主流的方案，在阿里普遍使用。
方案d，多熟中小企业靠业务补偿与人工订正解决。缺点是运维、支持投入人力大，优势是简单直接，逻辑不复杂。在业务量不大的状况下能hold住，但业务扩大了就很难应付。
这些问题很明显，为何没有产品解决？由于技术层面很难，缺少关键创新，这已是至少10多年的世界性难题了。这种状况下，GTS横空出世，经过一系列技术创新，但愿能完全解决这些问题。
从上面分析能够看出，方案b/c/d是由于a的性能知足不了业务需求的无奈之举。
作出一个一样知足事务ACID的强一致的通用分布式事务中间件，而且性能足够，简单易用，才是终极方案，这就是GTS的出发点。GTS产品能够经过技术创新，解决上述方案分析中b、c和d用户的问题，而不是寻求做为方案a用户的替代产品。
事务比较抽象，我举个例子类比下GTS给用户带来了哪些改变。
你天天上班，要通过一条10千米的只有两条车道的马路到达公司。这条路很堵，常常须要两三个小时，上班时间没有保证，这是方案a的问题。
选择一条很绕，长30千米但不多堵车的路，这是选b。上班时间有保证，可是必须早起，付出足够的时间和汽油。
选择一条有点绕，长20千米的山路，路不平，只有suv能够走，这是选c。上面分析了c方案场景受限，对应于交通，是底盘低的小轿车无法开，车型受限。
发扬艰苦奋斗，走路上班，这是选d。
GTS作的是什么？修了一条拥有4条车道的高架桥，没有绕路，仍是10千米。不堵车，对事务来讲是高性能；不绕路，对事务来讲是简单易用，对业务无侵入，不用为事务而重构；没有车型限制，对事务来讲是没有功能限制，提供强一致事务。在没有高架桥的时代，高架桥出现对交通来讲就是一个颠覆性创新，不少之前看来无解的问题就迎刃而解了，一样的，GTS但愿经过创新改变数据一致性处理的行业现状。
经过这个类比相信你们对GTS能够给用户带来的价值会有必定的了解。
下面咱们列出几个关键问题跟你们探讨下。
1）GTS是强一致，仍是最终一致？
2）GTS默认隔离级别是“读未提交”，对业务影响大吗？
3）GTS什么场景下不能保证数据严格一致？
GTS是强一致，不是最终一致。一致性和隔离性对多数用户很差区分，一致性对应事务ACID的“C”，隔离性对应的是“I”。
所谓强一致，在于用户发起事务提交或事务回滚获得确认后，数据已是一致的。而最终一致，用户发起提交，获得响应说提交成功了，可是未必真的成功，只是说过段时间它最终会数据一致。以转帐为例，转成功了你就必定当即能够查到是强一致，最终一致没有这种保证。
强一致这个概念有不少争论，不一样人有不一样理解，没有权威定义。咱们不搞学术化，你们理解实际业务中一致性是什么样子就行了。
隔离性与强一致没有必然联系。好比说把oracle的隔离级别设置为读未提交，这时oracle就不强一致了？显然仍是强一致。有人提出串行化的隔离级别才是强一致，那我想问，在生产系统你会把数据库隔离级别设置成串行化吗？显然绝大多数不会，这样理解的话，你们就别搞强一致了。
GTS支持两种隔离级别，“读未提交”和“读已提交”。“读未提交”比“读已提交”有明显性能优点，并且适合绝大多数场景，因此做为咱们默认隔离级别。
提起“读未提交”，你们第一反应是有脏读，会影响业务。真正分析下业务，会发现“读未提交”与“读已提交”的差异对业务有实际影响的场景不多。更多的场景是，若是你的业务逻辑在“读未提交”下有问题，在“读已提交”下一样存在问题；反之，“读已提交”下没有问题，在“读未提交”下也不多会存在问题。
还拿通俗易懂的转帐为例。假定A、B、C帐户各有10000元，帐户信息在不一样的数据库，有两个并发事务，事务1 A->B 1000元，事务2 A->C 2000元。转帐的业务逻辑是，先查出帐户余额，再根据转帐数目算出一个新余额来，而后用这个新余额去作update。
在“读未提交”状况下，事务1在进行中，事务2读到了A的帐户9000元，恰巧这时事务1发生故障回滚了，两个事务都完成后A 7000，B 10000，C 12000。数据不一致少了1000（A+B+C=29000），看来脏读不靠谱，可是再分析下，上面的逻辑在读已提交下，是否也存在问题？
在“读已提交”状况下，事务1在进行中，事务2读到了A的帐户10000元，两个事务都成功完成后A 8000，B 11000，C 12000。数据不一致多出1000（A+B+C=31000），看来也不靠谱啊。
问题根源在于上面的应用逻辑有典型的并发处理不当，修改办法不少，好比用select … for update 查询余额，能够锁定数据防止并发修改，或者是用sql中的逻辑运算代替，如 update … set value=value-2000。
咱们追求极致性能，引导用户用“读未提交”的思路来写分布式的业务逻辑，让绝大多数SQL获得更好性能，个别SQL必须用“读已提交”时才用。这比默认就用“读已提交”更加合理。
当用户用GTS事务操做数据，同时并发用非GTS方式（好比用oracle sqlplus）更改同一行数据，会影响到数据一致性。这种状况下，GTS校验发现数据被修改了，会发出告警到用户和咱们团队，用户能够经过咱们提供的工具进行订正（一般是点点按钮就ok了）。
问题的根本在于，GTS阻止不了别的方式写数据。因此，咱们建议用户须要用GTS操做的数据，作到用且仅用GTS，混着搞是不安全的。我想这种限制是合理的（别的方案也有相似限制，按规则出牌），已有用户都能接受。
在个别须要混用的特殊场景下，能够选择GTS和非GTS有个时间差的方式。好比有个用户是这样的，经过GTS处理订单，另有一个不走GTS的定时任务负责清理完成的订单。咱们建议用户的定时任务加个where条件只处理3分钟前的订单，这样就很安全了，由于业务中设置的GTS超时时长为1分钟，定时任务清理不会影响进行中的事务。
能够看到，很简单的业务逻辑就能够避免这种问题，作少许改造换来大幅性能提高是值得的。
经过本文的分析，相信你们对GTS产品有了全新的理解和认识，有兴趣的朋友，欢迎试用GTS。