談談分佈式事務

對於分佈式事務，用戶本質訴求是什麼？

分佈式事務解決的用戶最本質訴求是什麼？數據一致。

大中企業有一個共同的訴求是數據一致，幾乎覆蓋到各個行業。

好比說零售行業，庫存與出貨的數據須要保持一致，出貨量與庫存數據不匹配，顯而易見會出問題，拿到訂單卻沒貨了，或者有貨卻下不了訂單。

好比說金融行業，轉帳數據搞錯了，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年多，對分佈式系統下數據一致性問題有深刻理解，有興趣的朋友歡迎交流哈。