分佈式事務解決方案之XA/JTA兩階段提交方案,MQ消息最終一致性方案,TCC補償性方案

前言

本文主要講解不同場景下分佈式事務的解決方案,以及區別和相關理論。(部分圖片來自網絡)

一、分佈式事務的相關理論

CAP理論:

  • 一致性(Consistency)
  • 可用性(Availability)
  • 分區容錯(Partition-tolerance)
    一個分佈式系統最多隻能滿足以上的兩項,分區容錯性是分佈式系統必然需要面對和解決的問題,因此在一些大型互聯網公司都會把精力放在如何在C(一致性)和A(可用性)之間尋求平衡。

BASE理論

  • 基本可用(Basically Available)
    指分佈式系統在出現不可預知故障的時候,允許損失部分可用性。
  • 軟狀態( Soft State)
    指允許系統中的數據存在中間狀態,並認爲該中間狀態的存在不會影響系統的整體可用性,即允許系統在不同節點的數據副本之間進行數據同步的過程存在延時。
  • 最終一致( Eventual Consistency)
    強調的是所有的數據更新操作,在經過一段時間的同步之後,最終都能夠達到一個一致的狀態。因此,最終一致性的本質是需要系統保證最終數據能夠達到一致,而不需要實時保證系統數據的強一致性。
    BASE理論即在整體可用的情況下,滿足最終一致性,BASE理論可以說是CAP理論的拓展。

二、分佈式事務解決方案

1.跨庫事務(強一致性事務)

跨庫事務即在一個jvm內調用兩個數據庫。
XA是由X/Open組織提出的分佈式事務的規範,主要定義了:

  • (全局)事務管理器(Transaction Manager),承擔協調者(中間人transactionmanager)的身份
  • (局部)資源管理器(Resource Manager),通常是數據源
  • XA接口是雙向的系統接口,在事務管理器(Transaction Manager)以及一個或多個資源管理器(Resource Manager)之間形成通信橋樑。

JTA是XA協議在JAVA上上的實現,主要定義了:

  • 事務管理器的接口javax.transaction.TransactionManager,定義了有關事務的開始、提交、撤回等操作。
  • 滿足XA規範的資源定義接口javax.transaction.xa.XAResource,一種資源如果要支持JTA事務,就需要讓它的資源實現該XAResource接口,並實現該接口定義的兩階段提交相關的接口。

XA/JTA簡單來說就是一個兩階段提交協議,以下圖舉例。

  1. 準備階段:協調者(事務管理器Transaction Manager)詢問每個數據源(資源管理器 Resource Manager)。事務管理器詢問訂單庫和庫存庫,數據是否準備好,是否可以提交。
  2. 執行階段:如果數據源都回復可以提交數據,則協調者會把每個數據源的數據提交。如果數據源因爲資源不足(庫存不足)或網絡連接失敗等情況,回覆不可以提交,則協調者會把每個數據源的數據進行回滾。
    在這裏插入圖片描述
    常見的JTA實現Atomikos,TransactionEssentials。

2.跨JVM事務(柔性事務)

XA/JTA是強一致性事務,在分佈式系統中體現爲CP。雖然數據強一致,但在大型互聯網公司通常對AP與CP都有需求,此種方案明顯無法被使用。 大多數互聯網公司都採用基於BASE理論的柔性事務,兼顧AP與CP。

2.1.可靠消息最終一致性方案

可靠消息最終一致性方案是基於消息中間件的解決方案。
在確保消息服務可用的前提下,由生產者預發送消息給獨立消息服務存儲到數據庫,之後執行業務邏輯,執行完之後向消息服務發送確定發送消息,獨立消息服務將此消息發送到消息隊列中。此時消息消費者,在保證冪等性的前提下,消費消息,消費成功後並手動ack。如果在確認發送消息或ack因網絡等原因,一直無法執行時。獨立消息服務可以通過定時器,定時去相應服務查詢相關數據的狀態,進行自動確認發送和自動ack。
基於普通的消息隊列中間件
例子如下:
在這裏插入圖片描述
獨立消息服務定時任務的作用就是解決異常情況下,消息無法發送和消費成功無ACK的情況。但是如果消息消費的過程中出現了異常情況,且多次重試都無法成功的情況下,就需要人工干預。




2.2.TCC(Try-Confirm-Cancel)兩階段補償型方案無分佈式事務的下單場景TCC(Try-Confirm-Cancel)兩階段補償型方案的下單場景

累了,TCC(Try-Confirm-Cancel)就不再贅述了。T指資源預留,C資源確認,C資源回滾。
如下單,通常情況下只用寫一個接口。使用TCC方案下,需要寫三個接口,一個是資源預留接口,資源預留通常新增數據庫字段控制。一個是資源預留成功情況下的資源確定接口,一個是資源預留失敗情況下的資源回滾接口。
TCC開源框架實現:
Atomikos,tcc-transaction,ByteTcc


3.TCC與XA/JTA的對比

  • XA是資源層面的分佈式事務,強一致性,在兩階段提交的整個過程中,一直會持有資源的鎖
  • TCC是業務層面的分佈式事務,最終一致性,不會一直持有資源的鎖
    在這裏插入圖片描述
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章