怎么分析分布式事務常用解決方法

這期內容當中小編將會給大家帶來有關怎么分析分布式事務常用解決方法，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

分布式事務的解決方法

方案1：全局事務（DTP模型）

全局事務基于DTP模型實現。DTP是由X/Open組織提出的一種分布式事務模型——X/Open Distributed Transaction Processing Reference Model。它規定了要實現分布式事務，需要三種角色：

• AP：Application 應用系統它就是我們開發的業務系統，在我們開發的過程中，可以使用資源管理器提供的事務接口來實現分布式事務。

• TM：Transaction Manager 事務管理器

• 分布式事務的實現由事務管理器來完成，它會提供分布式事務的操作接口供我們的業務系統調用。這些接口稱為TX接口。

• 事務管理器還管理著所有的資源管理器，通過它們提供的XA接口來同一調度這些資源管理器，以實現分布式事務。

• DTP只是一套實現分布式事務的規范，并沒有定義具體如何實現分布式事務，TM可以采用2PC、3PC、Paxos等協議實現分布式事務。

• RM：Resource Manager 資源管理器

• 能夠提供數據服務的對象都可以是資源管理器，比如：數據庫、消息中間件、緩存等。大部分場景下，數據庫即為分布式事務中的資源管理器。

• 資源管理器能夠提供單數據庫的事務能力，它們通過XA接口，將本數據庫的提交、回滾等能力提供給事務管理器調用，以幫助事務管理器實現分布式的事務管理。

• XA是DTP模型定義的接口，用于向事務管理器提供該資源管理器(該數據庫)的提交、回滾等能力。

• DTP只是一套實現分布式事務的規范，RM具體的實現是由數據庫廠商來完成的。

實際方案：基于XA協議的兩階段提交

XA是一個分布式事務協議，由Tuxedo提出。XA中大致分為兩部分：事務管理器和本地資源管理器。其中本地資源管理器往往由數據庫實現，比如Oracle、DB2這些商業數據庫都實現了XA接口，而事務管理器作為全局的調度者，負責各個本地資源的提交和回滾。XA實現分布式事務的原理如下：

總的來說，XA協議比較簡單，而且一旦商業數據庫實現了XA協議，使用分布式事務的成本也比較低。但是，XA也有致命的缺點，那就是性能不理想，特別是在交易下單鏈路，往往并發量很高，XA無法滿足高并發場景。XA目前在商業數據庫支持的比較理想，在mysql數據庫中支持的不太理想，mysql的XA實現，沒有記錄prepare階段日志，主備切換回導致主庫與備庫數據不一致。許多nosql也沒有支持XA，這讓XA的應用場景變得非常狹隘。

方案2：基于可靠消息服務的分布式事務（事務消息中間件）

這種實現分布式事務的方式需要通過消息中間件來實現。假設有A和B兩個系統，分別可以處理任務A和任務B。此時系統A中存在一個業務流程，需要將任務A和任務B在同一個事務中處理。下面來介紹基于消息中間件來實現這種分布式事務。

• 在系統A處理任務A前，首先向消息中間件發送一條消息

• 消息中間件收到后將該條消息持久化，但并不投遞。此時下游系統B仍然不知道該條消息的存在。

• 消息中間件持久化成功后，便向系統A返回一個確認應答；

• 系統A收到確認應答后，則可以開始處理任務A；

• 任務A處理完成后，向消息中間件發送Commit請求。該請求發送完成后，對系統A而言，該事務的處理過程就結束了，此時它可以處理別的任務了。但commit消息可能會在傳輸途中丟失，從而消息中間件并不會向系統B投遞這條消息，從而系統就會出現不一致性。這個問題由消息中間件的事務回查機制完成，下文會介紹。

• 消息中間件收到Commit指令后，便向系統B投遞該消息，從而觸發任務B的執行；

• 當任務B執行完成后，系統B向消息中間件返回一個確認應答，告訴消息中間件該消息已經成功消費，此時，這個分布式事務完成。

上述過程可以得出如下幾個結論：

1. 消息中間件扮演者分布式事務協調者的角色。

2. 系統A完成任務A后，到任務B執行完成之間，會存在一定的時間差。在這個時間差內，整個系統處于數據不一致的狀態，但這短暫的不一致性是可以接受的，因為經過短暫的時間后，系統又可以保持數據一致性，滿足BASE理論。

上述過程中，如果任務A處理失敗，那么需要進入回滾流程。

• 若系統A在處理任務A時失敗，那么就會向消息中間件發送Rollback請求。和發送Commit請求一樣，系統A發完之后便可以認為回滾已經完成，它便可以去做其他的事情。

• 消息中間件收到回滾請求后，直接將該消息丟棄，而不投遞給系統B，從而不會觸發系統B的任務B。

此時系統又處于一致性狀態，因為任務A和任務B都沒有執行。

上面所介紹的Commit和Rollback都屬于理想情況，但在實際系統中，Commit和Rollback指令都有可能在傳輸途中丟失。那么當出現這種情況的時候，消息中間件是如何保證數據一致性呢？——答案就是超時詢問機制。

系統A除了實現正常的業務流程外，還需提供一個事務詢問的接口，供消息中間件調用。當消息中間件收到一條事務型消息后便開始計時，如果到了超時時間也沒收到系統A發來的Commit或Rollback指令的話，就會主動調用系統A提供的事務詢問接口詢問該系統目前的狀態。該接口會返回三種結果：

• 提交若獲得的狀態是“提交”，則將該消息投遞給系統B。

• 回滾若獲得的狀態是“回滾”，則直接將條消息丟棄。

• 處理中若獲得的狀態是“處理中”，則繼續等待。

消息中間件的超時詢問機制能夠防止上游系統因在傳輸過程中丟失Commit/Rollback指令而導致的系統不一致情況，而且能降低上游系統的阻塞時間，上游系統只要發出Commit/Rollback指令后便可以處理其他任務，無需等待確認應答。而Commit/Rollback指令丟失的情況通過超時詢問機制來彌補，這樣大大降低上游系統的阻塞時間，提升系統的并發度。

下面來說一說消息投遞過程的可靠性保證。當上游系統執行完任務并向消息中間件提交了Commit指令后，便可以處理其他任務了，此時它可以認為事務已經完成，接下來消息中間件一定會保證消息被下游系統成功消費掉！那么這是怎么做到的呢？這由消息中間件的投遞流程來保證。

消息中間件向下游系統投遞完消息后便進入阻塞等待狀態，下游系統便立即進行任務的處理，任務處理完成后便向消息中間件返回應答。消息中間件收到確認應答后便認為該事務處理完畢！

如果消息在投遞過程中丟失，或消息的確認應答在返回途中丟失，那么消息中間件在等待確認應答超時之后就會重新投遞，直到下游消費者返回消費成功響應為止。當然，一般消息中間件可以設置消息重試的次數和時間間隔，比如：當第一次投遞失敗后，每隔五分鐘重試一次，一共重試3次。如果重試3次之后仍然投遞失敗，那么這條消息就需要人工干預。

有的同學可能要問：消息投遞失敗后為什么不回滾消息，而是不斷嘗試重新投遞？

這就涉及到整套分布式事務系統的實現成本問題。我們知道，當系統A將向消息中間件發送Commit指令后，它便去做別的事情了。如果此時消息投遞失敗，需要回滾的話，就需要讓系統A事先提供回滾接口，這無疑增加了額外的開發成本，業務系統的復雜度也將提高。對于一個業務系統的設計目標是，在保證性能的前提下，最大限度地降低系統復雜度，從而能夠降低系統的運維成本。

不知大家是否發現，上游系統A向消息中間件提交Commit/Rollback消息采用的是異步方式，也就是當上游系統提交完消息后便可以去做別的事情，接下來提交、回滾就完全交給消息中間件來完成，并且完全信任消息中間件，認為它一定能正確地完成事務的提交或回滾。然而，消息中間件向下游系統投遞消息的過程是同步的。也就是消息中間件將消息投遞給下游系統后，它會阻塞等待，等下游系統成功處理完任務返回確認應答后才取消阻塞等待。為什么這兩者在設計上是不一致的呢？

首先，上游系統和消息中間件之間采用異步通信是為了提高系統并發度。業務系統直接和用戶打交道，用戶體驗尤為重要，因此這種異步通信方式能夠極大程度地降低用戶等待時間。此外，異步通信相對于同步通信而言，沒有了長時間的阻塞等待，因此系統的并發性也大大增加。但異步通信可能會引起Commit/Rollback指令丟失的問題，這就由消息中間件的超時詢問機制來彌補。

那么，消息中間件和下游系統之間為什么要采用同步通信呢？

異步能提升系統性能，但隨之會增加系統復雜度；而同步雖然降低系統并發度，但實現成本較低。因此，在對并發度要求不是很高的情況下，或者服務器資源較為充裕的情況下，我們可以選擇同步來降低系統的復雜度。我們知道，消息中間件是一個獨立于業務系統的第三方中間件，它不和任何業務系統產生直接的耦合，它也不和用戶產生直接的關聯，它一般部署在獨立的服務器集群上，具有良好的可擴展性，所以不必太過于擔心它的性能，如果處理速度無法滿足我們的要求，可以增加機器來解決。而且，即使消息中間件處理速度有一定的延遲那也是可以接受的，因為前面所介紹的BASE理論就告訴我們了，我們追求的是最終一致性，而非實時一致性，因此消息中間件產生的時延導致事務短暫的不一致是可以接受的。

方案3：最大努力通知（定期校對）也叫本地消息表

最大努力通知也被稱為定期校對，其實在方案二中已經包含，這里再單獨介紹，主要是為了知識體系的完整性。這種方案也需要消息中間件的參與。

• 上游系統在完成任務后，向消息中間件同步地發送一條消息，確保消息中間件成功持久化這條消息，然后上游系統可以去做別的事情了；

• 消息中間件收到消息后負責將該消息同步投遞給相應的下游系統，并觸發下游系統的任務執行；

• 當下游系統處理成功后，向消息中間件反饋確認應答，消息中間件便可以將該條消息刪除，從而該事務完成。

上面是一個理想化的過程，但在實際場景中，往往會出現如下幾種意外情況：

1. 消息中間件向下游系統投遞消息失敗

2. 上游系統向消息中間件發送消息失敗

對于第一種情況，消息中間件具有重試機制，我們可以在消息中間件中設置消息的重試次數和重試時間間隔，對于網絡不穩定導致的消息投遞失敗的情況，往往重試幾次后消息便可以成功投遞，如果超過了重試的上限仍然投遞失敗，那么消息中間件不再投遞該消息，而是記錄在失敗消息表中，消息中間件需要提供失敗消息的查詢接口，下游系統會定期查詢失敗消息，并將其消費，這就是所謂的“定期校對”。

如果重復投遞和定期校對都不能解決問題，往往是因為下游系統出現了嚴重的錯誤，此時就需要人工干預。

對于第二種情況，需要在上游系統中建立消息重發機制。可以在上游系統建立一張本地消息表，并將 任務處理過程 和 向本地消息表中插入消息 這兩個步驟放在一個本地事務中完成。如果向本地消息表插入消息失敗，那么就會觸發回滾，之前的任務處理結果就會被取消。如果這量步都執行成功，那么該本地事務就完成了。接下來會有一個專門的消息發送者不斷地發送本地消息表中的消息，如果發送失敗它會返回重試。當然，也要給消息發送者設置重試的上限，一般而言，達到重試上限仍然發送失敗，那就意味著消息中間件出現嚴重的問題，此時也只有人工干預才能解決問題。

對于不支持事務型消息的消息中間件，如果要實現分布式事務的話，就可以采用這種方式。它能夠通過重試機制+定期校對實現分布式事務，但相比于第二種方案，它達到數據一致性的周期較長，而且還需要在上游系統中實現消息重試發布機制，以確保消息成功發布給消息中間件，這無疑增加了業務系統的開發成本，使得業務系統不夠純粹，并且這些額外的業務邏輯無疑會占用業務系統的硬件資源，從而影響性能。

因此，盡量選擇支持事務型消息的消息中間件來實現分布式事務，如RocketMQ。

方案4：TCC（兩階段型、補償型）

跨應用的業務操作原子性要求，其實是比較常見的。比如在第三方支付場景中的組合支付，用戶在電商網站購物后，要同時使用余額和
紅包支付該筆訂單，而余額系統和紅包系統分別是不同的應用系統，支付系統在調用這兩個系統進行支付時，就需要保證余額扣減和紅
包使用要么同時成功，要么同時失敗。

TCC事務的出現正是為了解決應用拆分帶來的跨應用業務操作原子性的問題。當然，由于常規的XA事務(2PC，2 Phase Commit, 兩階段提交)
性能上不盡如人意，也有通過TCC事務來解決數據庫拆分的使用場景(如賬務拆分)，這個本文后續部分再詳述。

故從整個系統架構的角度來看，分布式事務的不同方案是存在層次結構的。

TCC的機制

明眼一看就知道，TCC應該是三個英文單詞的首字母縮寫而來。沒錯，TCC分別對應Try、Confirm和Cancel三種操作，
這三種操作的業務含義如下：

Try：預留業務資源Confirm：確認執行業務操作Cancel：取消執行業務操作

稍稍對照下關系型數據庫事務的三種操作：DML、Commit和Rollback，會發現和TCC有異曲同工之妙。在一個跨應用的業務操作中，
Try操作是先把多個應用中的業務資源預留和鎖定住，為后續的確認打下基礎，類似的，DML操作要鎖定數據庫記錄行，持有數據庫資源；
Confirm操作是在Try操作中涉及的所有應用均成功之后進行確認，使用預留的業務資源，和Commit類似；
而Cancel則是當Try操作中涉及的所有應用沒有全部成功，需要將已成功的應用進行取消(即Rollback回滾)。
其中Confirm和Cancel操作是一對反向業務操作。

簡而言之，TCC是應用層的2PC(2 Phase Commit, 兩階段提交)，如果你將應用看做資源管理器的話。
詳細來說，TCC每項操作需要做的事情如下：

1、Try：嘗試執行業務。
完成所有業務檢查(一致性)
預留必須業務資源(準隔離性)
2、Confirm：確認執行業務。
真正執行業務
不做任何業務檢查
只使用Try階段預留的業務資源
3、Cancel：取消執行業務
釋放Try階段預留的業務資源

一個完整的TCC事務參與方包括三部分：

主業務服務：主業務服務為整個業務活動的發起方，如前面提到的組合支付場景，支付系統即是主業務服務。
從業務服務：從業務服務負責提供TCC業務操作，是整個業務活動的操作方。從業務服務必須實現Try、Confirm和Cancel三個接口，
供主業務服務調用。
由于Confirm和Cancel操作可能被重復調用，故要求Confirm和Cancel兩個接口必須是冪等的。前面的組合支付場景中的余額系統和
紅包系統即為從業務服務。
業務活動管理器：業務活動管理器管理控制整個業務活動，包括記錄維護TCC全局事務的事務狀態和每個從業務服務的子事務狀態，并在業務活動提交時確認所有的TCC型操作的confirm操作，在業務活動取消時調用所有TCC型操作的cancel操作。
可見整個TCC事務對于主業務服務來說是透明的，其中業務活動管理器和從業務服務各自干了一部分工作。

TCC的優點和限制

TCC事務的優點如下：
解決了跨應用業務操作的原子性問題，在諸如組合支付、賬務拆分場景非常實用。
TCC實際上把數據庫層的二階段提交上提到了應用層來實現，對于數據庫來說是一階段提交，規避了數據庫層的2PC性能低下問題。

TCC事務的缺點，主要就一個：
TCC的Try、Confirm和Cancel操作功能需業務提供，開發成本高。
當然，對TCC事務的這個缺點是否是缺點，是一個見仁見智的事情。

一個案例理解

TCC說實話，TCC的理論有點讓人費解。故接下來將以賬務拆分為例，對TCC事務的流程做一個描述，希望對理解TCC有所幫助。
賬務拆分的業務場景如下，分別位于三個不同分庫的帳戶A、B、C，A和B一起向C轉帳共80元：分布式事務之說說TCC事務

1、Try：嘗試執行業務。
完成所有業務檢查(一致性)：檢查A、B、C的帳戶狀態是否正常，帳戶A的余額是否不少于30元，帳戶B的余額是否不少于50元。
預留必須業務資源(準隔離性)：帳戶A的凍結金額增加30元，帳戶B的凍結金額增加50元，這樣就保證不會出現其他并發進程扣減
了這兩個帳戶的余額而導致在后續的真正轉帳操作過程中，帳戶A和B的可用余額不夠的情況。

2、Confirm：確認執行業務。
真正執行業務：如果Try階段帳戶A、B、C狀態正常，且帳戶A、B余額夠用，則執行帳戶A給賬戶C轉賬30元、帳戶B給賬戶C轉賬50元的
轉帳操作。
不做任何業務檢查：這時已經不需要做業務檢查，Try階段已經完成了業務檢查。
只使用Try階段預留的業務資源：只需要使用Try階段帳戶A和帳戶B凍結的金額即可。

3、Cancel：取消執行業務
釋放Try階段預留的業務資源：如果Try階段部分成功，比如帳戶A的余額夠用，且凍結相應金額成功，帳戶B的余額不夠而凍結失敗，則需要對帳戶A做Cancel操作，將帳戶A被凍結的金額解凍掉。

上述就是小編為大家分享的怎么分析分布式事務常用解決方法了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。