分散式事務解決方案
背景
本地事務
一個單體應用中事務由一個數據庫管理,並且限制在單個程序中的事務.
不涉及多個數據來源.
優點:支援嚴格的ACID,可靠,高效,簡單.
不足:沒有分散式處理能力
隔離的最小單位有資源管理器(資料庫)決定,如果資料庫中的一條記錄或整張表(innodb能鎖一條記錄)
本地事務過程:
開始會話
開始事務
操作1,操作2…操作N
提交事務/回滾事務
完成會話
全域性事務(即標準分散式事務方案)
由全域性事務管理器管理
相關概念:
事務管理器:管理全域性事務狀態與參與的資源,協同資源的一致/回滾
TX協議:
應用或應用伺服器與事務管理器的介面
XA協議:
全域性事務管理器與資源管理器的介面
全域性事務過程:
開始全域性事務
註冊資源1
操作1,操作2…操作N
註冊資源2
操作1,操作2…操作N
提交事務
針對資源管理器1上進行準備
針對資源管理器2上進行準備
在 資源管理器1上提交
在 資源管理器2上提交
以上是通過兩階段提交來實現的,那麼什麼是兩階段提交呢?
兩階段提交:
是XA在全域性事務中協調多個資源的機制,採用兩階段方案來解決 一致性問題.由TM(相當於一個協調人)來參與事務最終提交.
事務管理器對資料庫1上進行準備,對資料庫2上進行準備,然後
提交資料庫1上的資料,提交資料庫2上的資料.
如果是回滾,也是同樣的操作.
在JAVA EE平臺中的標準分散式事務方案的如何實現?
通過jta(java 事務 API),和jts(java事務服務)來實現標準的分散式事務.
以上說的標準的分散式事務方案的實現由優點是:
符合嚴格的ACID,但是呢,
缺點是:
1 效率非常低,因為在全域性事務方式下,全域性事務管理器TM通過XA介面使用兩階段提交協議(2pc)與資源層(資料庫)互動時,資料被鎖定的時間跨越了整個事務,直到全域性事務結束,比如,一個事務跨了3個數據庫(這3個數據庫在3個不同的伺服器上,跨了伺服器和網路,會有各種網路延遲),那麼3個數據庫中的相關資料都會同時被鎖,直到事務全部完成後才解鎖,這種情況下其他的操作這些資料的動作都要一直等待.所以效率低
2 同時兩階段提交(2pc)在事務處理過程中,參與者需要一直持有資源,直到整個分散式事務結束,這樣當業務規模越來越大時,2pc侷限性越明顯,系統可伸縮性會很差.
3 XA協議系統開銷大,只有支援XA協議的資源才能參與分散式事務(目前主流資料庫都支援XA協議)
綜上,得出結論:微服務架構下使用標準分散式解決方案不適用.
那麼在微服務架構下如何處理分散式事務呢?
如下:
方案1
可靠訊息最終一致性
應用場景:
對應支付系統會計非同步記賬業務
銀行通知結果資訊儲存與驅動訂單處理
方案特點:
確保業務資料可靠的前提下,實現業務資料的最終一致,在理想狀態下基本是準實時一致.
行業應用案例:
支付寶,eBay,去哪兒
方案2
TCC事務補償型
應用場景:
對應支付系統訂單賬戶操作:訂單處理,資金賬戶處理,積分賬戶處理
行業應用案例:
螞蟻金融雲的分散式事務服務DTS
方案3
最大努力通知型
應用場景:
對應支付系統的商戶通知業務場景
行業應用案例:
銀行通知,商戶通知(多次通知,查詢校對,對賬檔案)
總結:
剛性事務
全域性事務(標準的分散式事務)
柔性事務:
可靠訊息最終一致性(非同步確認型)
TCC(兩階段型,補償型)
最大努力通知型(非可靠訊息,定期校對)
訊息中介軟體的應用場景
訊息中介軟體在分散式系統中的作用:
1 非同步通訊
2 解耦
3 併發緩衝