分布式事务方案这么多，到底应该如何选型？
生活随笔
收集整理的這篇文章主要介紹了
分布式事务方案这么多，到底应该如何选型？
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
戳藍字“CSDN云計算”關注我們哦！
與此同時，分布式事務的含義也在泛化，尤其SOA、微服務概念流行起來后，多指的是一個業務場景，需要編排很多獨立部署的服務時，如何保證交易整體的原子性與一致性問題。這類分布式事務也稱作長事務(long-lived transaction)，例如一個定行程的交易，它由購買航班、租車以及預訂酒店構成，而航班預訂可能需要一兩天才能確認。為了統一對概念的理解，本文默認指的都是這類長事務。分布式事務概念泛化的同時，也帶來了一個技術問題，微服務下這類分布式事務的ACID該如何保證？是否仍然可以用傳統兩階段提交/XA去解決？很可惜，基于數據庫的XA有點像扶不起的阿斗，中看不中用。二、為什么XA大家都不用？其實也并非不用，例如在IBM大型機上基于CICS很多跨資源是基于XA協議實現的分布式事務，事實上XA也算分布式事務處理的規范了，但在為什么互聯網中很少使用，究其原因我覺得有以下幾個：
Seata的使用方式以及原理在其github wiki上已經闡述的很清晰，網上也已有很多源代碼剖析的文章。接下來我們通過分析Seata AT模式原理，來看看它的亮點與問題。「Seata的使用方式以及原理」參考鏈接：https://github.com/seata/seata/wikiSeata對MT以及TCC的支持亮點有限，這兩種模式更多是為了兼容已有應用生態。Seata團隊畫了一個的詳細調用流程圖，對照此圖閱讀其源碼會輕松很多。
▲ Seata執行流程圖1、亮點相比與其它分布式事務框架，Seata架構的亮點主要有幾個：
另外undo log寫入時blob字段的插入性能也是不高的。每條寫SQL都會增加這么多開銷,粗略估計會增加5倍響應時間（二階段雖然是異步的，但其實也會占用系統資源，網絡、線程、數據庫）。前后鏡像如何生成？通過druid解析SQL，然后復用業務SQL中的where條件，然后生成Select SQL執行。
3、性價比為了進行自動補償，需要對所有交易生成前后鏡像并持久化，可是在實際業務場景下，這個是成功率有多高，或者說分布式事務失敗需要回滾的有多少比率？這個比例在不同場景下是不一樣的，考慮到執行事務編排前，很多都會校驗業務的正確性，所以發生回滾的概率其實相對較低。按照二八原則預估，即為了20%的交易回滾，需要將80%的成功交易的響應時間增加5倍，這樣的代價相比于讓應用開發一個補償交易是否是值得？值得我們深思。業界還有種思路，通過數據庫binlog恢復SQL執行前后鏡像，這樣省去了同步undo log生成記錄，減少了性能損耗，同時對業務零侵入，個人感覺是一種更好的方式。
4、全局鎖1）熱點數據Seata在每個分支事務中會攜帶對應的鎖信息，在before commit階段會依次獲取鎖(因為需要將所有SQL執行完才能拿到所有鎖信息，所以放在commit前判斷)。相比XA，Seata 雖然在一階段成功后會釋放數據庫鎖，但一階段在commit前全局鎖的判定也拉長了對數據鎖的占有時間，這個開銷比XA的prepare低多少需要根據實際業務場景進行測試。全局鎖的引入實現了隔離性，但帶來的問題就是阻塞，降低并發性，尤其是熱點數據，這個問題會更加嚴重。2）回滾鎖釋放時間Seata在回滾時，需要先刪除各節點的undo log，然后才能釋放TC內存中的鎖，所以如果第二階段是回滾，釋放鎖的時間會更長。3）死鎖問題Seata的引入全局鎖會額外增加死鎖的風險，但如果實現死鎖，會不斷進行重試，最后靠等待全局鎖超時，這種方式并不優雅，也延長了對數據庫鎖的占有時間。「Seata的引入全局鎖會額外增加死鎖的風險」參考鏈接：https://github.com/seata/awesome-seata/blob/master/wiki/en-us/Fescar-AT.md5、其他問題1）對于部分采用Seata的應用，如何保證數據不臟讀、幻讀？Seata提供了一個@GlobalLock的注解，可以提供輕量級全局鎖判定的功能（不生成undo log），但還是需要集成使用Seata。
2）TC在邏輯上是單點，如何做到高可用、高性能還是需要后續版本不斷優化。3）單機多數據源跨服務目前不支持。五、分布式事務的取舍嚴格的ACID事務對隔離性的要求很高，在事務執行中必須將所有的資源鎖定， 對于長事務來說，整個事務期間對數據的獨占，將嚴重影響系統并發性能。因此，在高并發場景中，對ACID的部分特性進行放松從而提高性能，這便產生了BASE柔性事務。柔性事務的理念則是通過業務邏輯將互斥鎖操作從資源層面上移至業務層面。通過放寬對強一致性要求，來換取系統吞吐量的提升。另外提供自動的異常恢復機制，可以在發生異常后也能確保事務的最終一致。
基于XA的分布式事務如果要嚴格保證ACID，實際需要事務隔離級別為SERLALIZABLE。由上可見柔性事務需要應用層進行參與，因此這類分布式事務框架一個首要的功能就是怎么最大程度降低業務改造成本，然后就是盡可能提高性能（響應時間、吞吐），最好是保證隔離性。一個好的分布式事務框架應用盡可能滿足以下特性：
「FLP不可能原理」參考鏈接：html%5D(https://www.cnblogs.com/firstdream/p/6585923.html)
其實由于網絡的不確定性，分布式下很多問題都是難題，最好的方案是避免分布式事務:)
最后回到主題，Seata解決了分布式事務難題了嗎？看你最在意哪方面了。如果你希望業務盡量少感知，DB操作簡單，那它會給你帶來驚喜；但如果你更看重響應時間，DB寫操作較多，調用鏈條較長，那它可能會讓失望。最后希望Seata開源項目越做越好！
福利掃描添加小編微信，備注“姓名+公司職位”，入駐【CSDN博客】，加入【云計算學習交流群】，和志同道合的朋友們共同打卡學習！
推薦閱讀：
作者 |?溫衛斌
責編 |?劉晶晶
源自 |?dbaplus社群
作者介紹
溫衛斌，就職于中國民生銀行信息科技部，目前負責分布式技術平臺設計與研發，主要關注分布式數據相關領域。
微服務興起的這幾年涌現出不少分布式事務框架，比如ByteTCC、TCC-transaction、EasyTransaction以及最近很火爆的Seata。最近剛看了Seata的源碼（v0.5.2），借機記錄一下自己對分布式事務的一些理解。（3年前這類框架還沒成熟，因項目需要自己也寫過一個柔性事務框架）。
本文分五部分，首先明確分布式事務概念的演變，然后簡單說下為什么大家不用XA，第三部分闡述兩階段提交的“提升”，第四部分介紹Seata的架構的亮點與問題，第五部分談下分布式事務的取舍。
限于篇幅一些網上可搜索的細節本文不展開闡述（例如XA、Saga、TCC、Seata等原理的的詳細介紹）。
一、分布式事務的泛化
提起分布式事務，最早指涉及的是多個資源的數據庫事務問題。
wiki對分布式事務的定義：A distributed transaction is a database transaction in which two or more network hosts are involved.
不過事務一詞含義隨著SOA架構逐漸擴大，根據上下文不同，可分為兩類：
- System transaction；
- Business transaction。
與此同時，分布式事務的含義也在泛化，尤其SOA、微服務概念流行起來后，多指的是一個業務場景，需要編排很多獨立部署的服務時，如何保證交易整體的原子性與一致性問題。這類分布式事務也稱作長事務(long-lived transaction)，例如一個定行程的交易，它由購買航班、租車以及預訂酒店構成，而航班預訂可能需要一兩天才能確認。為了統一對概念的理解，本文默認指的都是這類長事務。分布式事務概念泛化的同時，也帶來了一個技術問題，微服務下這類分布式事務的ACID該如何保證？是否仍然可以用傳統兩階段提交/XA去解決？很可惜，基于數據庫的XA有點像扶不起的阿斗，中看不中用。二、為什么XA大家都不用？其實也并非不用，例如在IBM大型機上基于CICS很多跨資源是基于XA協議實現的分布式事務，事實上XA也算分布式事務處理的規范了，但在為什么互聯網中很少使用，究其原因我覺得有以下幾個：
- 性能（阻塞性協議，增加響應時間、鎖時間、死鎖）；
- 數據庫支持完善度（MySQL 5.7之前都有缺陷）；
- 協調者依賴獨立的J2EE中間件（早期重量級Weblogic、Jboss、后期輕量級Atomikos、Narayana和Bitronix）；
- 運維復雜，DBA缺少這方面經驗；
- 并不是所有資源都支持XA協議；
- 大廠懂所以不使用，小公司不懂所以不敢用。
- 基于應用共享事務記錄執行軌跡；
- 然后通過異步重試確保交易最終一致（這也使得這種方式不適用那些業務上允許補償回滾的場景）。
- Saga的核心就是補償，一階段就是服務的正常順序調用（數據庫事務正常提交），如果都執行成功，則第二階段則什么都不做；但如果其中有執行發生異常，則依次調用其補償服務（一般多逆序調用未已執行服務的反交易）來保證整個交易的一致性。應用實施成本一般。
- TCC的特點在于業務資源檢查與加鎖，一階段進行校驗，資源鎖定，如果第一階段都成功，二階段對鎖定資源進行交易邏輯，否則，對鎖定資源進行釋放。應用實施成本較高。
- 基于可靠消息最終一致，一階段服務正常調用，同時同事務記錄消息表，二階段則進行消息的投遞，消費。應用實施成本較低。
- RM負責本地事務的提交，同時完成分支事務的注冊、鎖的判定，扮演事務參與者角色。
- TM負責整體事務的提交與回滾的指令的觸發，扮演事務的總體協調者角色。
Seata的使用方式以及原理在其github wiki上已經闡述的很清晰，網上也已有很多源代碼剖析的文章。接下來我們通過分析Seata AT模式原理，來看看它的亮點與問題。「Seata的使用方式以及原理」參考鏈接：https://github.com/seata/seata/wikiSeata對MT以及TCC的支持亮點有限，這兩種模式更多是為了兼容已有應用生態。Seata團隊畫了一個的詳細調用流程圖，對照此圖閱讀其源碼會輕松很多。
▲ Seata執行流程圖1、亮點相比與其它分布式事務框架，Seata架構的亮點主要有幾個：
- 應用層基于SQL解析實現了自動補償，從而最大程度的降低業務侵入性；
- 將分布式事務中TC（事務協調者）獨立部署，負責事務的注冊、回滾；
- 通過全局鎖實現了寫隔離與讀隔離。
另外undo log寫入時blob字段的插入性能也是不高的。每條寫SQL都會增加這么多開銷,粗略估計會增加5倍響應時間（二階段雖然是異步的，但其實也會占用系統資源，網絡、線程、數據庫）。前后鏡像如何生成？通過druid解析SQL，然后復用業務SQL中的where條件，然后生成Select SQL執行。
3、性價比為了進行自動補償，需要對所有交易生成前后鏡像并持久化，可是在實際業務場景下，這個是成功率有多高，或者說分布式事務失敗需要回滾的有多少比率？這個比例在不同場景下是不一樣的，考慮到執行事務編排前，很多都會校驗業務的正確性，所以發生回滾的概率其實相對較低。按照二八原則預估，即為了20%的交易回滾，需要將80%的成功交易的響應時間增加5倍，這樣的代價相比于讓應用開發一個補償交易是否是值得？值得我們深思。業界還有種思路，通過數據庫binlog恢復SQL執行前后鏡像，這樣省去了同步undo log生成記錄，減少了性能損耗，同時對業務零侵入，個人感覺是一種更好的方式。
4、全局鎖1）熱點數據Seata在每個分支事務中會攜帶對應的鎖信息，在before commit階段會依次獲取鎖(因為需要將所有SQL執行完才能拿到所有鎖信息，所以放在commit前判斷)。相比XA，Seata 雖然在一階段成功后會釋放數據庫鎖，但一階段在commit前全局鎖的判定也拉長了對數據鎖的占有時間，這個開銷比XA的prepare低多少需要根據實際業務場景進行測試。全局鎖的引入實現了隔離性，但帶來的問題就是阻塞，降低并發性，尤其是熱點數據，這個問題會更加嚴重。2）回滾鎖釋放時間Seata在回滾時，需要先刪除各節點的undo log，然后才能釋放TC內存中的鎖，所以如果第二階段是回滾，釋放鎖的時間會更長。3）死鎖問題Seata的引入全局鎖會額外增加死鎖的風險，但如果實現死鎖，會不斷進行重試，最后靠等待全局鎖超時，這種方式并不優雅，也延長了對數據庫鎖的占有時間。「Seata的引入全局鎖會額外增加死鎖的風險」參考鏈接：https://github.com/seata/awesome-seata/blob/master/wiki/en-us/Fescar-AT.md5、其他問題1）對于部分采用Seata的應用，如何保證數據不臟讀、幻讀？Seata提供了一個@GlobalLock的注解，可以提供輕量級全局鎖判定的功能（不生成undo log），但還是需要集成使用Seata。
2）TC在邏輯上是單點，如何做到高可用、高性能還是需要后續版本不斷優化。3）單機多數據源跨服務目前不支持。五、分布式事務的取舍嚴格的ACID事務對隔離性的要求很高，在事務執行中必須將所有的資源鎖定， 對于長事務來說，整個事務期間對數據的獨占，將嚴重影響系統并發性能。因此，在高并發場景中，對ACID的部分特性進行放松從而提高性能，這便產生了BASE柔性事務。柔性事務的理念則是通過業務邏輯將互斥鎖操作從資源層面上移至業務層面。通過放寬對強一致性要求，來換取系統吞吐量的提升。另外提供自動的異常恢復機制，可以在發生異常后也能確保事務的最終一致。
基于XA的分布式事務如果要嚴格保證ACID，實際需要事務隔離級別為SERLALIZABLE。由上可見柔性事務需要應用層進行參與，因此這類分布式事務框架一個首要的功能就是怎么最大程度降低業務改造成本，然后就是盡可能提高性能（響應時間、吞吐），最好是保證隔離性。一個好的分布式事務框架應用盡可能滿足以下特性：
- 業務改造成本低；
- 性能損耗低；
- 隔離性保證完整。
- 業務侵入性（基于注解、XML，補償邏輯）；
- 隔離性（寫隔離/讀隔離/讀未提交，業務隔離/技術隔離）；
- TM/TC部署形態（單獨部署、與應用部署一起）；
- 錯誤恢復（自動恢復、手動恢復）；
- 性能（回滾的概率、付出的代價,響應時間、吞吐）；
- 高可用（注冊中心、數據庫）；
- 持久化（數據庫、文件、多副本一致算法）；
- 同步/異步（2PC執行方式）；
- 日志清理(自動、手動)；
- ......
「FLP不可能原理」參考鏈接：html%5D(https://www.cnblogs.com/firstdream/p/6585923.html)
其實由于網絡的不確定性，分布式下很多問題都是難題，最好的方案是避免分布式事務:)
最后回到主題，Seata解決了分布式事務難題了嗎？看你最在意哪方面了。如果你希望業務盡量少感知，DB操作簡單，那它會給你帶來驚喜；但如果你更看重響應時間，DB寫操作較多，調用鏈條較長，那它可能會讓失望。最后希望Seata開源項目越做越好！
福利掃描添加小編微信，備注“姓名+公司職位”，入駐【CSDN博客】，加入【云計算學習交流群】，和志同道合的朋友們共同打卡學習！
推薦閱讀：
- 漫畫：什么是希爾排序？
- 一次失敗的面試，復習一次一致性哈希算法
Pandas中第二好用的函數 | 優雅的Apply
- 程序員因接外包坐牢 456 天！兩萬字揭露心酸經歷
限時早鳥票 | 2019 中國大數據技術大會（BDTC）超豪華盛宴搶先看
阿里開源物聯網操作系統 AliOS Things 3.0 發布，集成平頭哥 AI 芯片架構！
- 雷聲大雨點小：Bakkt「見光死」了嗎？
總結
以上是生活随笔為你收集整理的分布式事务方案这么多，到底应该如何选型？的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Boost：bind绑定的测试自定义占位
- 下一篇： Boost：bind的noexcept成