分布式事務

背景

在微服務環境下，因為會根據不同的業務會拆分成不同的服務，比如會員服務、訂單服務、商品服務等，讓專業的人做專業的事情，每個服務都有自己獨立的數據庫，并且是獨立運行，互不影響。但是每個服務中都有自己獨立的數據源，即自己獨立的本地事務。兩個服務相互通訊的時候，兩個本地事務互不影響，從而出現分布式事務產生的原因。

案例說明： 下單和扣庫存如何保持一致問題

描述：數據庫都是獨立的，每個獨立的數據源中都有自己獨立的事務，該事務成為本地事務。本地事務有效范圍在同一個jdbc里面(同一個事務管理器 )

代碼展示:

問題：下單失敗了，但是庫存成功了，如何去回滾？注意：下單成功，庫存失敗，不屬于分布式事務問題。

總結： 本地數據源有效范圍是 同一個jdbc連接或者同一個事務管理器。

分布式事務解決方案

剛性事務 -- 關系型數據庫的ACID

關系型數據庫天生就是解決具有復雜事務場景的問題，關系型數據庫完全滿足ACID的特性。滿足ACID特性

ACID對應的含義：事務管理(ACID)

談到事務一般都是以下四點:

原子性(Atomicity)：原子性是指事務是一個不可分割的工作單位，事務中的操作要么都發生，要么都不發生。

一致性(Consistency)：事務前后數據的完整性必須保持一致。

隔離性(Isolation)：事務的隔離性是多個用戶并發訪問數據庫時，數據庫為每一個用戶開啟的事務，不能被其他事務的操作數據所干擾，多個并發事務之間要相互隔離。

持久性(Durability)：持久性是指一個事務一旦被提交，它對數據庫中數據的改變就是永久性的，接下來即使數據庫發生故障也不應該對其有任何影響

柔性事務 -- 遵循Base和CPA理論

CPA理論

C:Consistency, 一致性。在分布式系統中的所有數據 備份，在同一時刻具有同樣的值，所有節點在同一時刻讀取的數據都是最新的數據副本。雙方進行通訊的時候，或者服務器集群的時候，一定要保證數據一致性問題，不能發生臟讀等問題。其實一般情況下可以做個取舍，可以暫時不遵循一致性，但是達到最終一致性，只要核心遵循下面的可用性和分區容忍性就可以。

A:Availability,可用性，好的響應性能。完全的可用性指的是在任何故障模型下，服務都會在有限的時間內處理完成并進行響應。比如服務器宕機情況下 還有備機

P: Partition tolerance,分區容錯性。盡管網絡上有部分消息丟失，但系統仍然可繼續工作。

總結：

CAP原理指的是，這三個要素最多只能同時實現兩點，不可能三者兼顧。

對于分布式數據系統，分區容忍性是基本要求，容錯是肯定的，否則就失去了價值，在一致性和可用性之間取一個平衡

對于大多數web應用，其實并不需要強一致性，因此犧牲一致性而換取高可用性，是目前多數分布式數據庫產品的方向。

通過軟狀態，可以暫時不一致，但是最終實現一致。通過補償、重試等。

犧牲一致性，只是不再要求關系型數據庫中的強一致性，而是只要系統能達到最終一致性即可

由于關系型數據庫是單節點無復制的，因此不具有分區容忍性，但是具有一致性和可用性，而分布式的服務化系統都需要滿足分區容忍性，那么我們必須在一致性和可用性之間進行權衡

注意實際開發中只遵循了P和A

Base 理論

BA:(Basically Available)，基本可用。指分布式系統在出現故障的時候，保證核心可用。比如：網頁訪問過大時，部分用戶提供降級服務。

S:(Soft State)，軟狀態，狀態可以在一段時間內不同步。

E:(Eventually Consistent)，最終一致，在一定的時間內，最終數據達成一致即可。

總結：BASE 思想與 ACID 原理截然不同，它滿足CAP原理，通過犧牲強一致性獲得可用性， 一般應用于服務化系統的應用層或者大數據處理系統中，通過達到最終一致性來盡量滿足業務的絕大多數需求。

支付案例

流程如下：

toov5 調用支付寶時候 會傳遞兩個參數 同步回調地址 和 異步回調地址

同步回調地址：支付完成后，支付寶采用瀏覽器方式重定向回調方

異步回調地址：支付完成后，采用后臺也就是HttpClient進行調用toov5接口通知支付接口

當通知接口出現延遲或者異常情況下，支付寶會發生自動重試。短暫的不一致情況

柔性事務分為：

兩階段型

補償型

異步確保型

最大努力通知型

關于兩階段、三階段

1. 兩階段： 交易中間件與數據庫通過 XA 接口規范，使用兩階段提交來完成一個全局事務， XA規范的基礎是兩階段提交協議。

準備階段：協調者向參與者發起指令，參與者評估自己的狀態，如果參與者評估指令可以完成，則會寫redo或者undo日志(提交日志和回滾日志)，然后鎖定資源，執行操作，但并不提交。

提交階段：協調者會向參與者發送一個指令，如果參與者收到指令后，會把該業務邏輯是否執行成功結果返回給協調者。如果參與者都返回執行成功，協調者在第二階段發送提交事務通知，如果有一方執行失敗，就會終止提交。

缺點：

如果協調者發生宕機，整個就沒法指揮協調了。庫存服務和訂單服務會一直等待。

兩階段提交方案鎖定資源時間長，對性能影響很大，基本不適合解決微服務事務問題。

技術落地:

Jta+Atomikos 屬于兩階段提交協議。底層是基于XA協議，主流數據庫MySQL等都支持XA協議。這個協議規范就是協調者把指令發送給參與者的過程。MySQL是參與者，Atomikos:Atomikos TransactionsEssentials是一個為Java平臺提供增值服務的并且開源類事務管理器，底層就是遵循了XA協議的規范。

Jta+Atomikos 代碼案例

1. 三階段提交協議 --- 兩階段準備階段再加了一個詢問階段

詢問階段：協調者詢問參與者是否可以完成指令，協調者只需要回答是還是不是，而不需要做真正的操作，這個階段超時導致中止。協調者和參與者執行的任務中都增加了超時，一旦超時，協調者和參與者都繼續提交事務，默認為成功，這也是根據概率統計上超時后默認成功的正確性最大。

優點：至少不會阻塞和永遠鎖定資源。

結合非關系型數據庫

但當數據庫要開始滿足橫向擴展、高可用、模式自由等需求時，需要對ACID理論進行取舍，不能嚴格遵循ACID。以CAP理論和BASE理論為基礎的NoSQL數據庫開始出現。

由于NoSQL的基本需求就是支持分布式存儲，嚴格一致性與可用性需要互相取舍，由此延伸出了CAP理論來定義分布式存儲遇到的問題。

總結

以上是生活随笔為你收集整理的18c分布式事务 oracle_分布式事务的现象及理解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。