M01.分佈式事務及其中間件介紹

爲什麼需要分佈式事務

我們知道ACID（原子性Atomicity、一致性Consistency、隔離性Isolation、持久性Durability）定義了單個數據庫操作的事務性，這樣我們就能放心的使用數據庫，而不用擔心數據的一致性，操作的原子性等等。由於數據庫同時可以併發的給多個應用、多個會話線程使用，這樣就涉及到了鎖，隔離級別和數據可見性等一系列工作，好在關係數據庫都已經幫我們解決了這些問題。
但是在SOA、分佈式服務化和微服務架構的大背景下，數據拆分到多個不同的庫已經是常態，這種改造或者設計中，同一個業務處理涉及到的關聯數據生命週期可能要貫穿到多個不同的數據庫，如果沒有事務保證，那麼數據的一致性或者正確性就會收到破壞，賬就可能會錯亂了，平臺或者客戶就會產生損失了。如何保證數據的事務性，則是一個非常有意思的話題。傳統的數據庫和消息系統一般都是支持XA分佈式事務，通過一個TM事務管理器協調各個RM資管管理器，每個RM管理自己的本地事務，通過兩階段提交2PC來保障一致。
由於CAP的不可能三角約束下，我們大部分時候選擇了從ACID到BASE（Basically Available基本可用, Soft-state柔性狀態, Eventually consistent最終一致），這樣分佈式事務我們一般也從XA變成了TCC（Try-Commit-Cancel），把分佈式事務的控制權從底層資源層（比如數據庫）挪到了業務實現層，從而通過釋放數據庫層的鎖，來提升性能和靈活性。具體情況可以參閱下面的各個參考文檔。

分佈式事務講的比較透徹：

• 分佈式事務綜述：https://mp.weixin.qq.com/s/sy_PKHc_km6uZ3TgJYfRnw
• 分佈式事務解決方案與適用場景分析：https://mp.weixin.qq.com/s/Okvgn5beGy5aJypfu6mKcg

螞蟻的分佈式事務中間件

1. 深度剖析一站式分佈式事務方案 Seata-Server：https://mp.weixin.qq.com/s/bjEyqExlaA6yZdJ5m7xJ7g
2. 分佈式事務 Seata Saga 模式首秀以及三種模式詳解：https://mp.weixin.qq.com/s/67NvEVljnU-0-6rb7MWpGw
3. ShardingSphere x Seata，一致性更強的分佈式數據庫中間件：https://mp.weixin.qq.com/s/nI6xqLwWgnrRocbSuPVcIA
4. 螞蟻金服大規模分佈式事務實踐和開源歷程：https://mp.weixin.qq.com/s/qGnPpI6VHz9_hfY0vZPa5A
5. 分佈式事務 Seata TCC 模式深度解析：https://mp.weixin.qq.com/s/G9vkficqBSpmtGITgsJPgw
6. 螞蟻金服分佈式事務開源以及實踐：https://mp.weixin.qq.com/s/S283Hs6tOXH30qyQowkYuQ
7. 更開放的分佈式事務 | 螞蟻金服共建 Seata 社區：https://mp.weixin.qq.com/s/qgzSGyGshWg4nWegFrRE0Q
8. 爲你解讀 SOFA-DTX 分佈式事務的設計演進路線下篇：https://mp.weixin.qq.com/s/TEMtJoN4CU6bpc7epEFI7g
9. 爲你解讀 SOFA-DTX 分佈式事務的設計演進路線上篇：https://mp.weixin.qq.com/s/vj3i3Eu50FZk68j7RoW_ZA
10. 一篇文章爲你解讀SOFA-DTX 分佈式事務的設計演進路線：https://mp.weixin.qq.com/s/Jsh1vYBPc62duyQCAKOtsg

分佈式事務的模式

1、TXC模式，使用MVCC快照模式
https://blog.csdn.net/m0_38110132/article/details/77043580
一、原理介紹：
TXC模式命名來源於淘寶，實現原理是在執行SQL之前，先查詢SQL的影響數據，然後保存執行的SQL快走信息和創建鎖。當需要回滾的時候就採用這些記錄數據回滾數據庫，目前鎖實現依賴redis分佈式鎖控制。
二、模式特點:
該模式同樣對代碼的嵌入性低。
該模式僅限於對支持SQL方式的模塊支持。
該模式由於每次執行SQL之前需要先查詢影響數據，因此消耗資源與時間要多。
該模式不會佔用數據庫的連接資源。
2、TCC事務模式
一、原理介紹:
TCC事務機制相對於傳統事務機制（X/Open XA Two-Phase-Commit），其特徵在於它不依賴資源管理器(RM)對XA的支持，而是通過對（由業務系統提供的）業務邏輯的調度來實現分佈式事務。主要由三步操作，Try: 嘗試執行業務、 Confirm:確認執行業務、 Cancel: 取消執行業務。
二、模式特點:
該模式對代碼的嵌入性高，要求每個業務需要寫三種步驟的操作。
該模式對有無本地事務控制都可以支持使用面廣。
數據一致性控制幾乎完全由開發者控制，對業務開發難度要求高。

微服務架構下分佈式事務

發現一個好玩的，有人實現了一個可以給dubbp和spring cloud提供XA分佈式事務的開源框架。
LCN distributed transaction framework, compatible with dubbo, spring cloud and Motan framework, supports various relational databases。
地址：

• https://www.txlcn.org/zh-cn/docs/demo/env.html
• https://github.com/codingapi/tx-lcn

ShardingSphere對分佈式事務的說明

在單一數據節點中，事務僅限於對單一數據庫資源的訪問控制，稱之爲本地事務。幾乎所有的成熟的關係型數據庫都提供了對本地事務的原生支持。 但是在基於微服務的分佈式應用環境下，越來越多的應用場景要求對多個服務的訪問及其相對應的多個數據庫資源能納入到同一個事務當中，分佈式事務應運而生。

關係型數據庫雖然對本地事務提供了完美的ACID原生支持。 但在分佈式的場景下，它卻成爲系統性能的桎梏。如何讓數據庫在分佈式場景下滿足ACID的特性或找尋相應的替代方案，是分佈式事務的重點工作。

本地事務

在不開啓任何分佈式事務管理器的前提下，讓每個數據節點各自管理自己的事務。 它們之間沒有協調以及通信的能力，也並不互相知曉其他數據節點事務的成功與否。 本地事務在性能方面無任何損耗，但在強一致性以及最終一致性方面則力不從心。

兩階段提交

XA協議最早的分佈式事務模型是由X/Open國際聯盟提出的X/Open Distributed Transaction Processing（DTP）模型，簡稱XA協議。

基於XA協議實現的分佈式事務對業務侵入很小。 它最大的優勢就是對使用方透明，用戶可以像使用本地事務一樣使用基於XA協議的分佈式事務。 XA協議能夠嚴格保障事務ACID特性。

嚴格保障事務ACID特性是一把雙刃劍。 事務執行在過程中需要將所需資源全部鎖定，它更加適用於執行時間確定的短事務。 對於長事務來說，整個事務進行期間對數據的獨佔，將導致對熱點數據依賴的業務系統併發性能衰退明顯。 因此，在高併發的性能至上場景中，基於XA協議的分佈式事務並不是最佳選擇。

柔性事務

如果將實現了ACID的事務要素的事務稱爲剛性事務的話，那麼基於BASE事務要素的事務則稱爲柔性事務。 BASE是基本可用、柔性狀態和最終一致性這三個要素的縮寫。

• 基本可用（Basically Available）保證分佈式事務參與方不一定同時在線。
• 柔性狀態（Soft state）則允許系統狀態更新有一定的延時，這個延時對客戶來說不一定能夠察覺。
• 最終一致性（Eventually consistent）通常是通過消息傳遞的方式保證系統的最終一致性。

在ACID事務中對隔離性的要求很高，在事務執行過程中，必須將所有的資源鎖定。 柔性事務的理念則是通過業務邏輯將互斥鎖操作從資源層面上移至業務層面。通過放寬對強一致性要求，來換取系統吞吐量的提升。

基於ACID的強一致性事務和基於BASE的最終一致性事務都不是銀彈，只有在最適合的場景中才能發揮它們的最大長處。 可通過下表詳細對比它們之間的區別，以幫助開發者進行技術選型。

	本地事務	兩（三）階段事務	柔性事務
業務改造	無	無	實現相關接口
一致性	不支持	支持	最終一致
隔離性	不支持	支持	業務方保證
併發性能	無影響	嚴重衰退	略微衰退
適合場景	業務方處理不一致	短事務 & 低併發	長事務 & 高併發

挑戰

由於應用的場景不同，需要開發者能夠合理的在性能與功能之間權衡各種分佈式事務。

強一致的事務與柔性事務的API和功能並不完全相同，在它們之間並不能做到自由的透明切換。在開發決策階段，就不得不在強一致的事務和柔性事務之間抉擇，使得設計和開發成本被大幅增加。

基於XA的強一致事務使用相對簡單，但是無法很好的應對互聯網的高併發或複雜系統的長事務場景；柔性事務則需要開發者對應用進行改造，接入成本非常高，並且需要開發者自行實現資源鎖定和反向補償。

目標

整合現有的成熟事務方案，爲本地事務、兩階段事務和柔性事務提供統一的分佈式事務接口，並彌補當前方案的不足，提供一站式的分佈式事務解決方案是ShardingSphere分佈式事務模塊的主要設計目標。