分布式事務雲市場分析

全局事務服務gts上個月開始在阿裡雲上公測，之前我們也發表了一篇「破解世界性技術難題！gts讓分布式事務簡單高效」的文章，引起了業界廣泛關注，接受了大量的咨詢，故希望通過本文讓大家對gts有更深入的了解。

gts在目前在阿裡内外部已經有較大規模的應用，有100多個使用者，其中專有雲大使用者就有10多個，預計今年将有更大規模的市場需求爆發。

<a></a>

分布式事務解決的使用者最本質訴求是什麼？資料一緻。

大中企業有一個共同的訴求是資料一緻，幾乎覆寫到各個行業。

比如說零售行業，庫存與出貨的資料需要保持一緻，出貨量與庫存資料不比對，顯而易見會出問題，拿到訂單卻沒貨了，或者有貨卻下不了訂單。

比如說金融行業，轉賬資料搞錯了，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-&gt;b 1000元，事務2 a-&gt;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分鐘，定時任務清理不會影響進行中的事務。

可以看到，很簡單的業務邏輯就可以避免這種問題，做少量改造換來大幅性能提升是值得的。