分布式事務如何解決？一次講清楚！

作者：佚名 2021-07-07 10:28:09

新聞

前端

分布式 事務指的就是一個操作單元，在這個操作單元中的所有操作最終要保持一致的行為，要么所有操作都成功，要么所有的操作都被撤銷。簡單地說，事務提供一種“要么什么都不做，要么做全套”機制。

  [[409803]]

分布式事務基礎

事務

事務指的就是一個操作單元，在這個操作單元中的所有操作最終要保持一致的行為，要么所有操作都成功，要么所有的操作都被撤銷。簡單地說，事務提供一種“要么什么都不做，要么做全套”機制。

本地事務

本地事務其實可以認為是數(shù)據(jù)庫提供的事務機制。說到數(shù)據(jù)庫事務就不得不說，數(shù)據(jù)庫事務中的四大特性:

A：原子性(Atomicity) ，一個事務中的所有操作，要么全部完成，要么全部不完成

C：一致性(Consistency) ，在一個事務執(zhí)行之前和執(zhí)行之后數(shù)據(jù)庫都必須處于一致性狀態(tài)

I：隔離性(Isolation) ，在并發(fā)環(huán)境中，當不同的事務同時操作相同的數(shù)據(jù)時，事務之間互不影響

D：持久性(Durability) ，指的是只要事務成功結束，它對數(shù)據(jù)庫所做的更新就必須永久的保存下來

數(shù)據(jù)庫事務在實現(xiàn)時會將一次事務涉及的所有操作全部納入到一個不可分割的執(zhí)行單元，該執(zhí)行單元中的所有操作要么都成功，要么都失敗，只要其中任一操作執(zhí)行失敗，都將導致整個事務的回滾。

分布式事務

分布式事務指事務的參與者、支持事務的服務器、資源服務器以及事務管理器分別位于不同的分布式系統(tǒng)的不同節(jié)點之上。

簡單的說，就是一次大的操作由不同的小操作組成，這些小的操作分布在不同的服務器上，且屬于不同的應用，分布式事務需要保證這些小操作要么全部成功，要么全部失敗。

本質上來說，分布式事務就是為了保證不同數(shù)據(jù)庫的數(shù)據(jù)一致性。

分布式事務的場景

• 單體系統(tǒng)訪問多個數(shù)據(jù)庫

  一個服務需要調用多個數(shù)據(jù)庫實例完成數(shù)據(jù)的增刪改操作

 

 

 

 

 

 

• 多個微服務訪問同一個數(shù)據(jù)庫

  多個服務需要調用一個數(shù)據(jù)庫實例完成數(shù)據(jù)的增刪改操作

 

 

 

 

 

 

• 多個微服務訪問多個數(shù)據(jù)庫

  多個服務需要調用一個數(shù)據(jù)庫實例完成數(shù)據(jù)的增刪改操作

 

 

 

 

 

 

分布式事務解決方案

全局事務

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

• AP: Application 應用系統(tǒng) (微服務)

• TM: Transaction Manager 事務管理器 (全局事務管理)

• RM: Resource Manager 資源管理器 (數(shù)據(jù)庫)

整個事務分成兩個階段:

階段一: 表決階段，所有參與者都將本事務執(zhí)行預提交，并將能否成功的信息反饋發(fā)給協(xié)調者。

階段二: 執(zhí)行階段，協(xié)調者根據(jù)所有參與者的反饋，通知所有參與者，步調一致地執(zhí)行提交或者回滾。

 

 

 

 

優(yōu)點：

• 提高了數(shù)據(jù)一致性的概率，實現(xiàn)成本較低

缺點：

• 單點問題：事務協(xié)調者宕機

• 同步阻塞: 延遲了提交時間，加長了資源阻塞時間

• 數(shù)據(jù)不一致: 提交第二階段，依然存在commit結果未知的情況，有可能導致數(shù)據(jù)不一致

可靠消息服務

基于可靠消息服務的方案是通過消息中間件保證上、下游應用數(shù)據(jù)操作的一致性。

假設有A和B兩個系統(tǒng)，分別可以處理任務A和任務B。此時存在一個業(yè)務流程，需要將任務A和任務B在同一個事務中處理。就可以使用消息中間件來實現(xiàn)這種分布式事務。

 

 

 

 

第一步: 消息由系統(tǒng)A投遞到中間件

1. 在系統(tǒng)A處理任務A前，首先向消息中間件發(fā)送一條消息

2. 消息中間件收到后將該條消息持久化，但并不投遞。持久化成功后，向A回復一個確認應答

3. 系統(tǒng)A收到確認應答后，則可以開始處理任務A

4. 任務A處理完成后，向消息中間件發(fā)送Commit或者Rollback請求。該請求發(fā)送完成后，對系統(tǒng)A而言，該事務的處理過程就結束了

5. 如果消息中間件收到Commit，則向B系統(tǒng)投遞消息；如果收到Rollback，則直接丟棄消息。但是如果消息中間件收不到Commit和Rollback指令，那么就要依靠"超時詢問機制"。

超時詢問機制 系統(tǒng)A除了實現(xiàn)正常的業(yè)務流程外，還需提供一個事務詢問的接口，供消息中間件調用。當消息中間件收到發(fā)布消息便開始計時，如果到了超時沒收到確認指令，就會主動調用系統(tǒng)A提供的事務詢問接口詢問該系統(tǒng)目前的狀態(tài)。該接口會返回三種結果，中間件根據(jù)三種結果做出不同反應：

• 提交:將該消息投遞給系統(tǒng)B

• 回滾:直接將條消息丟棄

• 處理中:繼續(xù)等待

第二步: 消息由中間件投遞到系統(tǒng)B

消息中間件向下游系統(tǒng)投遞完消息后便進入阻塞等待狀態(tài)，下游系統(tǒng)便立即進行任務的處理，任務處理完成后便向消息中間件返回應答。

• 如果消息中間件收到確認應答后便認為該事務處理完畢

• 如果消息中間件在等待確認應答超時之后就會重新投遞，直到下游消費者返回消費成功響應為止。

基于可靠消息服務的分布式事務，前半部分使用異步，注重性能；后半部分使用同步，注重開發(fā)成本。

最大努力通知

最大努力通知也被稱為定期校對，其實是對第二種解決方案的進一步優(yōu)化。它引入了本地消息表來記錄錯誤消息，然后加入失敗消息的定期校對功能，來進一步保證消息會被下游系統(tǒng)消費。

 

 

 

 

第一步: 消息由系統(tǒng)A投遞到中間件

1. 處理業(yè)務的同一事務中，向本地消息表中寫入一條記錄

2. 準備專門的消息發(fā)送者不斷地發(fā)送本地消息表中的消息到消息中間件，如果發(fā)送失敗則重試

第二步: 消息由中間件投遞到系統(tǒng)B

1. 消息中間件收到消息后負責將該消息同步投遞給相應的下游系統(tǒng)，并觸發(fā)下游系統(tǒng)的任務執(zhí)行

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

3. 對于投遞失敗的消息，利用重試機制進行重試，對于重試失敗的，寫入錯誤消息表

4. 消息中間件需要提供失敗消息的查詢接口，下游系統(tǒng)會定期查詢失敗消息，并將其消費

這種方式的優(yōu)缺點：

優(yōu)點：一種非常經(jīng)典的實現(xiàn)，實現(xiàn)了最終一致性。

缺點：消息表會耦合到業(yè)務系統(tǒng)中，如果沒有封裝好的解決方案，會有很多雜活需要處理。

TCC事務

TCC即為Try Confirm Cancel，它屬于補償型分布式事務。TCC實現(xiàn)分布式事務一共有三個步驟：

• Try：嘗試待執(zhí)行的業(yè)務 這個過程并未執(zhí)行業(yè)務，只是完成所有業(yè)務的一致性檢查，并預留好執(zhí)行所需的全部資源

• Confirm：確認執(zhí)行業(yè)務 確認執(zhí)行業(yè)務操作，不做任何業(yè)務檢查， 只使用Try階段預留的業(yè)務資源。

• Cancel：取消待執(zhí)行的業(yè)務 取消Try階段預留的業(yè)務資源。

 

 

 

 

TCC兩階段提交與XA兩階段提交的區(qū)別是：

XA是資源層面的分布式事務，強一致性，在兩階段提交的整個過程中，一直會持有資源的鎖。

TCC是業(yè)務層面的分布式事務，最終一致性，不會一直持有資源的鎖。

TCC事務的優(yōu)缺點：

優(yōu)點：

把數(shù)據(jù)庫層的二階段提交上提到了應用層來實現(xiàn)，規(guī)避了數(shù)據(jù)庫層的2PC性能低下問題。

缺點：

TCC的Try、Confirm和Cancel操作功能需業(yè)務提供，開發(fā)成本高。

SAGA

Saga 是一種補償協(xié)議，在 Saga 模式下，分布式事務內有多個參與者，每一個參與者都是一個沖正補償服務，需要用戶根據(jù)業(yè)務場景實現(xiàn)其正向操作和逆向回滾操作。

 

 

 

 

補償協(xié)議：在Saga模式下，分布式事務內有多個參與者，每個參與者都是正向補償服務。上圖中的 T1~Tn 就是 正向調用 ， C1~Cn 是 補償調用 ，正向調用和補償調用是一一對應的關系。

假設有n個被調用方服務， T1 就是對服務一的調用，接著 T2 是對服務方二的調用，T3是對服務方三的調用。如果這個時候返回了失敗，那么就需要進行回滾，此時就會調用 T2 的對應補償 C2 ，調用 T1 的對應補償 C1 ，使得分布式事務回到初始狀態(tài)。

Saga 正向服務與補償服務都需要業(yè)務開發(fā)者實現(xiàn)，因此是業(yè)務入侵的。Saga 模式下分布式事務通常是由事件驅動的，各個參與者之間是異步執(zhí)行的，Saga 模式是一種長事務解決方案。

Saga 模式使用場景

Saga 模式適用于業(yè)務流程長且需要保證事務最終一致性的業(yè)務系統(tǒng)，Saga 模式一階段就會提交本地事務，無鎖、長流程情況下可以保證性能。

事務參與者可能是其它公司的服務或者是遺留系統(tǒng)的服務，無法進行改造和提供 TCC 要求的接口，可以使用 Saga 模式。

Saga模式的優(yōu)勢與缺點

優(yōu)勢：

一階段提交本地數(shù)據(jù)庫事務，無鎖，高性能；

參與者可以采用事務驅動異步執(zhí)行，高吞吐 補償服務即正向服務的“反向”，易于理解，易于實現(xiàn)；

缺點：

Saga 模式由于一階段已經(jīng)提交本地數(shù)據(jù)庫事務，且沒有進行“預留”動作，所以不能保證隔離性。

SEATA

2019 年 1 月，阿里巴巴中間件團隊發(fā)起了開源項目 Fescar（Fast & EaSy Commit AndRollback），其愿景是讓分布式事務的使用像本地事務的使用一樣，簡單和高效，并逐步解決開發(fā)者們遇到的分布式事務方面的所有難題。后來更名為 Seata，意為：Simple Extensible AutonomousTransaction Architecture，是一套分布式事務解決方案。

Seata的設計目標是對業(yè)務無侵入，因此從業(yè)務無侵入的2PC方案著手，在傳統(tǒng)2PC的基礎上演進。它把一個分布式事務理解成一個包含了若干分支事務的全局事務。全局事務的職責是協(xié)調其下管轄的分支事務達成一致，要么一起成功提交，要么一起失敗回滾。此外，通常分支事務本身就是一個關系數(shù)據(jù)庫的本地事務。

 

 

 

 

Seata主要由三個重要組件組成：

TC：Transaction Coordinator 事務協(xié)調器，管理全局的分支事務的狀態(tài)，用于全局性事務的提交和回滾。

TM：Transaction Manager 事務管理器，用于開啟、提交或者回滾全局事務。

RM：Resource Manager 資源管理器，用于分支事務上的資源管理，向TC注冊分支事務，上報分支事務的狀態(tài)，接受TC的命令來提交或者回滾分支事務。

 

 

 

 

Seata的執(zhí)行流程如下:

1. A服務的TM向TC申請開啟一個全局事務，TC就會創(chuàng)建一個全局事務并返回一個唯一的XID

2. A服務的RM向TC注冊分支事務，并及其納入XID對應全局事務的管轄

3. A服務執(zhí)行分支事務，向數(shù)據(jù)庫做操作

4. A服務開始遠程調用B服務，此時XID會在微服務的調用鏈上傳播

5. B服務的RM向TC注冊分支事務，并將其納入XID對應的全局事務的管轄

6. B服務執(zhí)行分支事務，向數(shù)據(jù)庫做操作

7. 全局事務調用鏈處理完畢，TM根據(jù)有無異常向TC發(fā)起全局事務的提交或者回滾

8. TC協(xié)調其管轄之下的所有分支事務， 決定是否回滾

Seata實現(xiàn)2PC與傳統(tǒng)2PC的差別：

1. 架構層次方面，傳統(tǒng)2PC方案的 RM 實際上是在數(shù)據(jù)庫層，RM本質上就是數(shù)據(jù)庫自身，通過XA協(xié)議實現(xiàn)，而 Seata的RM是以jar包的形式作為中間件層部署在應用程序這一側的。

2. 兩階段提交方面，傳統(tǒng)2PC無論第二階段的決議是commit還是rollback，事務性資源的鎖都要保持到Phase2完成才釋放。而Seata的做法是在Phase1 就將本地事務提交，這樣就可以省去Phase2持鎖的時間，整體提高效率。

 

 

網(wǎng)站欄目：分布式事務如何解決？一次講清楚！
文章出自：http://fisionsoft.com.cn/article/djhcdho.html