點擊上方“朱小廝的博客”，選擇“設為星標”

回復”1024“獲取獨家整理的學習資料

微服務興起的這幾年涌現(xiàn)出不少分布式事務框架，比如ByteTCC、TCC-transaction、EasyTransaction以及最近很火爆的Seata。最近剛看了Seata的源碼（v0.5.2），借機記錄一下自己對分布式事務的一些理解。（3年前這類框架還沒成熟，因項目需要自己也寫過一個柔性事務框架）。

本文分五部分，首先明確分布式事務概念的演變，然后簡單說下為什么大家不用XA，第三部分闡述兩階段提交的“提升”，第四部分介紹Seata的架構的亮點與問題，第五部分談下分布式事務的取舍。

限于篇幅一些網(wǎng)上可搜索的細節(jié)本文不展開闡述（例如XA、Saga、TCC、Seata等原理的的詳細介紹）。

一、分布式事務的泛化

提起分布式事務，最早指涉及的是多個資源的數(shù)據(jù)庫事務問題。

wiki對分布式事務的定義：A distributed transaction is a database transaction in which two or more network hosts are involved.

不過事務一詞含義隨著SOA架構逐漸擴大，根據(jù)上下文不同，可分為兩類：

• System transaction；

• Business transaction。

前者多指數(shù)據(jù)庫事務，后者則多對應一個業(yè)務交易。

與此同時，分布式事務的含義也在泛化，尤其SOA、微服務概念流行起來后，多指的是一個業(yè)務場景，需要編排很多獨立部署的服務時，如何保證交易整體的原子性與一致性問題。這類分布式事務也稱作長事務(long-lived transaction)，例如一個定行程的交易，它由購買航班、租車以及預訂酒店構成，而航班預訂可能需要一兩天才能確認。為了統(tǒng)一對概念的理解，本文默認指的都是這類長事務。

分布式事務概念泛化的同時，也帶來了一個技術問題，微服務下這類分布式事務的ACID該如何保證？是否仍然可以用傳統(tǒng)兩階段提交/XA去解決？很可惜，基于數(shù)據(jù)庫的XA有點像扶不起的阿斗，中看不中用。

二、為什么XA大家都不用？

其實也并非不用，例如在IBM大型機上基于CICS很多跨資源是基于XA協(xié)議實現(xiàn)的分布式事務，事實上XA也算分布式事務處理的規(guī)范了，但在為什么互聯(lián)網(wǎng)中很少使用，究其原因我覺得有以下幾個：

• 性能（阻塞性協(xié)議，增加響應時間、鎖時間、死鎖）；

• 數(shù)據(jù)庫支持完善度（MySQL 5.7之前都有缺陷）；

• 協(xié)調(diào)者依賴獨立的J2EE中間件（早期重量級Weblogic、Jboss、后期輕量級Atomikos、Narayana和Bitronix）；

• 運維復雜，DBA缺少這方面經(jīng)驗；

• 并不是所有資源都支持XA協(xié)議；

• 大廠懂所以不使用，小公司不懂所以不敢用。

準確講XA是一個規(guī)范、協(xié)議，它只是定義了一系列的接口，只是目前大多數(shù)實現(xiàn)XA的都是數(shù)據(jù)庫或者MQ，所以提起XA往往多指基于資源層的底層分布式事務解決方案。其實現(xiàn)在也有些數(shù)據(jù)分片框架或者中間件也支持XA協(xié)議，畢竟它的兼容性、普遍性更好。

三、兩階段提交的“提升”

基于數(shù)據(jù)庫的XA協(xié)議本質(zhì)上就是兩階段提交，但由于性能原因在互聯(lián)網(wǎng)高并發(fā)場景下并不適用。如果數(shù)據(jù)庫只能保證本地ACID時，那么其中出現(xiàn)交易異常后，如何實現(xiàn)整個交易原子性A，從而保證一致性C呢？另外在處理過程中如何保證隔離性呢？

最直接的方法就是按照邏輯依次調(diào)用服務，但出現(xiàn)異常怎么辦?那就對那些已經(jīng)成功的進行補償，補償成功就一致了，這種樸素的模型就是Saga。但Saga這種方式并不能保證隔離性，于是出現(xiàn)了TCC。在實際交易邏輯前先做業(yè)務檢查、對涉及到的業(yè)務資源進行“預留”，或者說是一種“中間狀態(tài)”，如果都預留成功則完成這些預留資源的真正業(yè)務處理，典型的如票務座位等場景。

當然還有像Ebay提出的基于消息表，即可靠消息最終一致模型，但本質(zhì)上這也屬于Saga模式的一種特定實現(xiàn)，它的關鍵點有兩個：

• 基于應用共享事務記錄執(zhí)行軌跡；

• 然后通過異步重試確保交易最終一致（這也使得這種方式不適用那些業(yè)務上允許補償回滾的場景）。

這類分布式事務場景并不是微服務才出現(xiàn)的，在SOA時代其實就有了，常見的Saga、TCC、可靠消息最終一致等模型也都是很多年前就有了，只是最近幾年隨著微服務興起，這些方案又重新被人關注了起來。

「Saga」參考鏈接：https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf

仔細對比這些方案與XA，會發(fā)現(xiàn)這些方案本質(zhì)上都是將兩階段提交從資源層提升到了應用層。

• Saga的核心就是補償，一階段就是服務的正常順序調(diào)用（數(shù)據(jù)庫事務正常提交），如果都執(zhí)行成功，則第二階段則什么都不做；但如果其中有執(zhí)行發(fā)生異常，則依次調(diào)用其補償服務（一般多逆序調(diào)用未已執(zhí)行服務的反交易）來保證整個交易的一致性。應用實施成本一般。

• TCC的特點在于業(yè)務資源檢查與加鎖，一階段進行校驗，資源鎖定，如果第一階段都成功，二階段對鎖定資源進行交易邏輯，否則，對鎖定資源進行釋放。應用實施成本較高。

• 基于可靠消息最終一致，一階段服務正常調(diào)用，同時同事務記錄消息表，二階段則進行消息的投遞，消費。應用實施成本較低。

具體到基于這些模型實現(xiàn)的分布式事務框架，也多借鑒了DTP（Distributed Transaction Processing）模型。

DTP（Distributed Transaction Processing）參考鏈接：http://pubs.opengroup.org/onlinepubs/009680699/toc.pdf

▲ DTP模型

• RM負責本地事務的提交，同時完成分支事務的注冊、鎖的判定，扮演事務參與者角色。

• TM負責整體事務的提交與回滾的指令的觸發(fā)，扮演事務的總體協(xié)調(diào)者角色。

不同框架在實現(xiàn)時，各組件角色的功能、部署形態(tài)會根據(jù)需求進行調(diào)整，例如TM有的是以jar包形式與應用部署在一起，有的則剝離出來需要單獨部署（例如Seata中將TM的主要功能放到一個邏輯上集中的Server上，叫做TC( Transaction Coordinator )）

四、Seata架構得與失

今年初，阿里發(fā)布了開源分布式事務框架Fescar，后來跟螞蟻TCC方案整合后改名為Seata，目前版本雖然只到0.6，但GitHub star已經(jīng)過9k，一方面可見阿里在圈內(nèi)推廣能力，另外一方面也說明大家對阿里分布式事務框架的期待。

Seata的使用方式以及原理在其github wiki上已經(jīng)闡述的很清晰，網(wǎng)上也已有很多源代碼剖析的文章。接下來我們通過分析Seata AT模式原理，來看看它的亮點與問題。

「Seata的使用方式以及原理」參考鏈接：https://github.com/seata/seata/wiki

Seata對MT以及TCC的支持亮點有限，這兩種模式更多是為了兼容已有應用生態(tài)。

Seata團隊畫了一個的詳細調(diào)用流程圖，對照此圖閱讀其源碼會輕松很多。

▲ Seata執(zhí)行流程圖

1、亮點

相比與其它分布式事務框架，Seata架構的亮點主要有幾個：

• 應用層基于SQL解析實現(xiàn)了自動補償，從而最大程度的降低業(yè)務侵入性；

• 將分布式事務中TC（事務協(xié)調(diào)者）獨立部署，負責事務的注冊、回滾；

• 通過全局鎖實現(xiàn)了寫隔離與讀隔離。

這些特性的具體實現(xiàn)機制其官網(wǎng)以及github上都有詳細介紹，這里不展開介紹。

2、性能損耗

我們看看Seata增加了哪些開銷（純內(nèi)存運算類的忽略不計）：

一條Update的SQL，則需要全局事務xid獲取（與TC通訊）、before image（解析SQL，查詢一次數(shù)據(jù)庫）、after image（查詢一次數(shù)據(jù)庫）、insert undo log（寫一次數(shù)據(jù)庫）、before commit（與TC通訊，判斷鎖沖突），這些操作都需要一次遠程通訊RPC，而且是同步的。

另外undo log寫入時blob字段的插入性能也是不高的。每條寫SQL都會增加這么多開銷,粗略估計會增加5倍響應時間（二階段雖然是異步的，但其實也會占用系統(tǒng)資源，網(wǎng)絡、線程、數(shù)據(jù)庫）。

前后鏡像如何生成？

通過druid解析SQL，然后復用業(yè)務SQL中的where條件，然后生成Select SQL執(zhí)行。

3、性價比

為了進行自動補償，需要對所有交易生成前后鏡像并持久化，可是在實際業(yè)務場景下，這個是成功率有多高，或者說分布式事務失敗需要回滾的有多少比率？這個比例在不同場景下是不一樣的，考慮到執(zhí)行事務編排前，很多都會校驗業(yè)務的正確性，所以發(fā)生回滾的概率其實相對較低。按照二八原則預估，即為了20%的交易回滾，需要將80%的成功交易的響應時間增加5倍，這樣的代價相比于讓應用開發(fā)一個補償交易是否是值得？值得我們深思。

業(yè)界還有種思路，通過數(shù)據(jù)庫binlog恢復SQL執(zhí)行前后鏡像，這樣省去了同步undo log生成記錄，減少了性能損耗，同時對業(yè)務零侵入，個人感覺是一種更好的方式。

4、全局鎖

1）熱點數(shù)據(jù)

Seata在每個分支事務中會攜帶對應的鎖信息，在before commit階段會依次獲取鎖(因為需要將所有SQL執(zhí)行完才能拿到所有鎖信息，所以放在commit前判斷)。相比XA，Seata 雖然在一階段成功后會釋放數(shù)據(jù)庫鎖，但一階段在commit前全局鎖的判定也拉長了對數(shù)據(jù)鎖的占有時間，這個開銷比XA的prepare低多少需要根據(jù)實際業(yè)務場景進行測試。全局鎖的引入實現(xiàn)了隔離性，但帶來的問題就是阻塞，降低并發(fā)性，尤其是熱點數(shù)據(jù)，這個問題會更加嚴重。

2）回滾鎖釋放時間

Seata在回滾時，需要先刪除各節(jié)點的undo log，然后才能釋放TC內(nèi)存中的鎖，所以如果第二階段是回滾，釋放鎖的時間會更長。

3）死鎖問題

Seata的引入全局鎖會額外增加死鎖的風險，但如果實現(xiàn)死鎖，會不斷進行重試，最后靠等待全局鎖超時，這種方式并不優(yōu)雅，也延長了對數(shù)據(jù)庫鎖的占有時間。

「Seata的引入全局鎖會額外增加死鎖的風險」參考鏈接：https://github.com/seata/awesome-seata/blob/master/wiki/en-us/Fescar-AT.md

5、其他問題

1）對于部分采用Seata的應用，如何保證數(shù)據(jù)不臟讀、幻讀？

Seata提供了一個@GlobalLock的注解，可以提供輕量級全局鎖判定的功能（不生成undo log），但還是需要集成使用Seata。

2）TC在邏輯上是單點，如何做到高可用、高性能還是需要后續(xù)版本不斷優(yōu)化。

3）單機多數(shù)據(jù)源跨服務目前不支持。

五、分布式事務的取舍

嚴格的ACID事務對隔離性的要求很高，在事務執(zhí)行中必須將所有的資源鎖定， 對于長事務來說，整個事務期間對數(shù)據(jù)的獨占，將嚴重影響系統(tǒng)并發(fā)性能。因此，在高并發(fā)場景中，對ACID的部分特性進行放松從而提高性能，這便產(chǎn)生了BASE柔性事務。柔性事務的理念則是通過業(yè)務邏輯將互斥鎖操作從資源層面上移至業(yè)務層面。通過放寬對強一致性要求，來換取系統(tǒng)吞吐量的提升。另外提供自動的異常恢復機制，可以在發(fā)生異常后也能確保事務的最終一致。

基于XA的分布式事務如果要嚴格保證ACID，實際需要事務隔離級別為SERLALIZABLE。

由上可見柔性事務需要應用層進行參與，因此這類分布式事務框架一個首要的功能就是怎么最大程度降低業(yè)務改造成本，然后就是盡可能提高性能（響應時間、吞吐），最好是保證隔離性。

一個好的分布式事務框架應用盡可能滿足以下特性：

• 業(yè)務改造成本低；

• 性能損耗低；

• 隔離性保證完整。

但如同CAP，這三個特性是相互制衡的，往往只能滿足其中兩個，我們可以畫一個三角約束：

基于業(yè)務補償?shù)腟aga滿足1.2；TCC滿足2.3；Seata滿足1.3。

當然如果我們要自己設計一個分布式事務框架，還需要考慮很多其它特性，在明確目標場景偏好后進行權衡取舍，這些特性包括但不限于以下：

• 業(yè)務侵入性（基于注解、XML，補償邏輯）；

• 隔離性（寫隔離/讀隔離/讀未提交，業(yè)務隔離/技術隔離）；

• TM/TC部署形態(tài)（單獨部署、與應用部署一起）；

• 錯誤恢復（自動恢復、手動恢復）；

• 性能（回滾的概率、付出的代價,響應時間、吞吐）；

• 高可用（注冊中心、數(shù)據(jù)庫）；

• 持久化（數(shù)據(jù)庫、文件、多副本一致算法）；

• 同步/異步（2PC執(zhí)行方式）；

• 日志清理(自動、手動)；

• ......

六、結語

分布式事務一直是業(yè)界難題，難在于CAP定理，在于分布式系統(tǒng)8大錯誤假設，在于FLP不可能原理，在于我們習慣于單機事務ACID做對比。無論是數(shù)據(jù)庫領域XA、Google percolator或Calvin模型，還是微服務下Saga、TCC、可靠消息等方案，都沒有完美解決分布式事務問題，它們不過是各自在性能、一致性、可用性等方面做取舍，尋求某些場景偏好下的權衡。

「分布式系統(tǒng)8大錯誤假設」參考鏈接：http://%5Bhttps://en.wikipedia.org/wiki/Fallacies_of_distributed_computing%5D(https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing)

「FLP不可能原理」參考鏈接：html%5D(https://www.cnblogs.com/firstdream/p/6585923.html)

其實由于網(wǎng)絡的不確定性，分布式下很多問題都是難題，最好的方案是避免分布式事務:)

最后回到主題，Seata解決了分布式事務難題了嗎？看你最在意哪方面了。如果你希望業(yè)務盡量少感知，DB操作簡單，那它會給你帶來驚喜；但如果你更看重響應時間，DB寫操作較多，調(diào)用鏈條較長，那它可能會讓失望。最后希望Seata開源項目越做越好！

作者：溫衛(wèi)斌，就職于中國民生銀行信息科技部，目前負責分布式技術平臺設計與研發(fā)，主要關注分布式數(shù)據(jù)相關領域。

來源：DBAplus社群

---

想知道更多？掃描下面的二維碼關注我

相關推薦：

• 《科普 | 明星公司之Netflix》

• 《看我如何作死 | 將CPU、IO打爆》

• 《看我如何作死 | 網(wǎng)絡延遲、丟包、中斷一個都沒落下》

• 《干貨 |?阿里巴巴混沌測試工具ChaosBlade兩萬字解讀》

加技術群入口（備注：技術）：>>>Learn More<<

免費資料入口（備注：1024）：>>>Learn More<<

免費星球入口：>>>Free<<<

內(nèi)推通道>>>>

點個"在看"唄^_^

總結

以上是生活随笔為你收集整理的分布式事务选型的取舍 | 建议收藏的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。