如何進行分庫分表中多數據源的事務處理

這期內容當中小編將會給大家?guī)碛嘘P如何進行分庫分表中多數據源的事務處理，文章內容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

系統(tǒng)經sharding改造之后，原來單一的數據庫會演變成多個數據庫，如何確保多數據源同時操作的原子性和一致性是不得不考慮的一個問題?？傮w上看，目前對于一個分布式系統(tǒng)的事務處理有三種方式：分布式事務、基于Best  Efforts 1PC模式的事務以及事務補償機制。我們下面對這三種處理方式一一進行分析。

分布式事務

這是最為人們所熟知的多數據源事務處理機制。本文并不打算對分布式事務做過多介紹，讀者可參考此文：關于分布式事務、兩階段提交、一階段提交、Best  Efforts 1PC模式和事務補償機制的研究 。在這里只想對分布式事務的利弊作一下分析。

優(yōu)勢：

1. 基于兩階段提交，最大限度地保證了跨數據庫操作的“原子性”，是分布式系統(tǒng)下最嚴格的事務實現方式。

2.  實現簡單，工作量小。由于多數應用服務器以及一些獨立的分布式事務協(xié)調器做了大量的封裝工作，使得項目中引入分布式事務的難度和工作量基本上可以忽略不計。

劣勢：

系統(tǒng)“水平”伸縮的死敵。基于兩階段提交的分布式事務在提交事務時需要在多個節(jié)點之間進行協(xié)調,***限度地推后了提交事務的時間點，客觀上延長了事務的執(zhí)行時間，這會導致事務在訪問共享資源時發(fā)生沖突和死鎖的概率增高，隨著數據庫節(jié)點的增多，這種趨勢會越來越嚴重，從而成為系統(tǒng)在數據庫層面上水平伸縮的”枷鎖”，  這是很多Sharding系統(tǒng)不采用分布式事務的主要原因。

基于Best Efforts 1PC模式的事務

與分布式事務采用的兩階段提交不同，Best Efforts  1PC模式采用的是一階段端提交，犧牲了事務在某些特殊情況(當機、網絡中斷等)下的安全性，卻獲得了良好的性能，特別是消除了對水平伸縮的桎酷。Distributed  transactions in Spring, with and without XA一文對Best Efforts  1PC模式進行了詳細的說明，該文提供的Demo代碼更是直接給出了在Spring環(huán)境下實現一階段提交的多數據源事務管理示例。不過需要注意的是，原示例是基于spring  3.0之前的版本，如果你使用spring 3.0+,會得到如下錯誤：java.lang.IllegalStateException: Cannot  activate transaction synchronization – already active，如果使用spring  3.0+，你需要參考spring-data-neo4j的實現。鑒于Best Efforts  1PC模式的性能優(yōu)勢，以及相對簡單的實現方式，它被大多數的sharding框架和項目采用。

事務補償機制

對于那些對性能要求很高，但對一致性要求并不高的系統(tǒng)，往往并不苛求系統(tǒng)的實時一致性，只要在一個允許的時間周期內達到最終一致性即可，這使得事務補償機制成為一種可行的方案。事務補償機制最初被提出是在“長事務”的處理中，但是對于分布式系統(tǒng)確保一致性也有很好的參考意義?；\統(tǒng)地講，與事務在執(zhí)行中發(fā)生錯誤后立即回滾的方式不同，事務補償是一種事后檢查并補救的措施，它只期望在一個容許時間周期內得到最終一致的結果就可以了。事務補償的實現與系統(tǒng)業(yè)務緊密相關，并沒有一種標準的處理方式。一些常見的實現方式有：對數據進行對帳檢查;基于日志進行比對;定期同標準數據來源進行同步，等等。

分布式事務，最嚴格的事務實現，但性能是個大問題;Best Efforts  1PC模式，性能與事務可靠性的平衡，支持系統(tǒng)水平伸縮，大多數情況下是最合適的選擇;事務補償機制，只能適用于對事務性要求不高，允許數據“最終一致”即可的系統(tǒng)，犧牲實時一致性，獲得最大的性能回報。

上述就是小編為大家分享的如何進行分庫分表中多數據源的事務處理了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業(yè)資訊頻道。