ShardingSphere 4.x 分佈式事務

背景

數據庫事務須要知足ACID(原子性、一致性、隔離性、持久性)四個特性。數據庫

  • 原子性(Atomicity)指事務做爲總體來執行,要麼所有執行,要麼全不執行。
  • 一致性(Consistency)指事務應確保數據從一個一致的狀態轉變爲另外一個一致的狀態。
  • 隔離性(Isolation)指多個事務併發執行時,一個事務的執行不該影響其餘事務的執行。
  • 持久性(Durability)指已提交的事務修改數據會被持久保存。

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

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

本地事務

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

兩階段提交

XA協議最先的分佈式事務模型是由X/Open國際聯盟提出的X/Open Distributed Transaction Processing(DTP)模型,簡稱XA協議。高併發

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

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

柔性事務

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

  • 基本可用(Basically Available)保證分佈式事務參與方不必定同時在線。
  • 柔性狀態(Soft state)則容許系統狀態更新有必定的延時,這個延時對客戶來講不必定可以察覺。
  • 而最終一致性(Eventually consistent)一般是經過消息傳遞的方式保證系統的最終一致性。

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

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

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

挑戰

因爲應用的場景不一樣,須要開發者可以合理的在性能與功能之間權衡各類分佈式事務。

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

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

目標

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

相關文章
相關標籤/搜索