對於分布式事務，用戶本質訴求是什么？
分布式事務解決的用戶最本質訴求是什么？數據一致。
大中企業有一個共同的訴求是數據一致，幾乎覆蓋到各個行業。
比如說零售行業，庫存與出貨的數據需要保持一致，出貨量與庫存數據不匹配，顯而易見會出問題，拿到訂單卻沒貨了，或者有貨卻下不了訂單。
比如說金融行業，轉賬數據搞錯了，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年多，對分布式系統下數據一致性問題有深入理解，有興趣的朋友歡迎交流哈。