分布式事務及解決方案

2021-10-05 09:32:53 字數 2006 閱讀 7211

最近看了一些分布式事務相關的資料,決定記錄下來。

參考文章:

要了解分布式事務,首先要知道事務的四大特性:acid

所謂分布式事務,即分布式場景下的事務問題,如場景:服務a中的方法a()呼叫服務b中的方法b()和服務c中的方法c(),由於三個方法屬於三個不同的服務,相互呼叫需要通過遠端連線的方式進行呼叫,此時三個服務中的三個方法訪問資料庫屬於不同的訪問連線;

/**

* a服務中的方法a

* @throws exception

*/@transactional(rollbackfor =exception.class)

public void a()throws exception

/**

* b服務中的方法b

* @throws exception

*/@transactional(rollbackfor =exception.class)

public void b()throws exception

/**

* c服務中的方法c

* @throws exception

*/@transactional(rollbackfor =exception.class)

public void c()throws exception

事務情況分析:

1、方法a首先呼叫b方法,若b方法呼叫失敗並丟擲異常,此時b方法資料庫操作未執行成功事務回滾,然後a方法捕獲到b方法丟擲的異常,終端後面**的執行,尚未執行其他資料庫操作,此時無分布式事務問題。

2、方法a首先呼叫b方法,若b方法呼叫成功,此時b方法資料庫操作成功事務執行完畢,然後a方法繼續呼叫c服務中的c方法,若此時c方法執行失敗並丟擲異常,則c方法中的本地事務回滾,然後a方法捕獲c方法丟擲的異常,並終止後面**的執行丟擲異常,但此時b方法中的本地事務已經執行完畢,無法回滾(只有捕獲到異常時回滾),此時則就出現了b方法和c方法事務不一致問題,即分布式事務問題。為了解決b和c事務不一致的問題,此時應該想辦法去通知b回滾事務,即分布式事務的解決方案之一。

3、當然,此時如果a呼叫b和c都成功,但執行a本方法內的資料庫操作時失敗了,同樣也是分布式事務問題,因為它無法通知b、c事務進行回滾。

其實,單體服務中也存在分布式事務問題,當上述a、b、c三個方法在同乙個服務中,但是三個方法需要操作三個不同的資料庫時,由於是不同的資料庫訪問連線,此時同樣會出現上面同樣的問題,也屬於分布式事務問題。

分布式事務解決方法:

xa:xa協議,規定事務管理器和資源管理器介面,採用二階段提交協議。 xa 規範主要定義了事務管理器(transaction manager)和區域性資源管理器(local resource manager)之間的介面。

兩段式提交的核心是事務管理器,由事務管理器進行對參與事務的資源進行管理

優點:能夠解決分布式事務問題,原理簡單,實現方便;

缺點:同步阻塞,因為事務管理器要收集各個資源管理器的響應訊息,如果其中乙個或多個一直不返回訊息,則事務管理器一直等待,應用程式也被阻塞,甚至可能永久阻塞。

2、tcc三段式事務補償提交方法

所謂tcc即,try.....confirm.....cancel其將整個業務邏輯的每個分支顯式的分成了try、confirm、cancel三個操作。tcc方案其實是兩階段提交的一種改進,tcc方案在電商、金融領域落地較多。

tcc的核心思想是"參與事務的應用程式都應該提供三個http介面,由乙個事務協調者進行整體事務的協調"try介面:預留業務資源;跟普通的操作操作差不多,只是有個status來標識為預生效;

confirm介面:確認執行業務操作;update status改為生效;

cancel介面:取消執行業務操作;如果有報錯,那麼多個分介面都需要需求,比如把status該為取消等。

具體實現可參考文章:

事務 分布式事務解決方案

事務acid特性 事務隔離級別 指的是讀和寫同時出現時出現的資料不一致問題。事務的一致性問題 存在問題問題描述 髒讀 dirty read 針對的是單條資料。即乙個更新操作a修改了某一條資料,但尚未提交該事務,此時另乙個讀操作b來查詢該條資料,讀到的是修改後的但尚未提交的資料。不可重複讀 unrep...

分布式事務解決方案

一 結合mq訊息中介軟體實現的可靠訊息最終一致性 二 tcc補償性事務解決 三 最大努力通知型方案 第一種方案 可靠訊息最終一致性,需要業務系統結合mq訊息中介軟體實現,在實現過程中需要保證訊息的成功傳送及成功消費。即需要通過業務系統控制mq的訊息狀態 第二種方案 tcc補償性,分為三個階段tryi...

分布式事務解決方案

當資料庫單錶一年產生的資料超過1000w,那麼就要考慮分庫分表,具體分庫分表的原理在此不做解釋,以後有空詳細說,簡單的說就是原來的乙個資料庫變成了多個資料庫。這時候,如果乙個操作既訪問01庫,又訪問02庫,而且要保證資料的一致性,那麼就要用到分布式事務。所謂的soa化,就是業務的服務化。比如原來單機...