[[409803]]

分布式事務(wù)基礎(chǔ)

事務(wù)

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

本地事務(wù)

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

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

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

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

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

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

分布式事務(wù)

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

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

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

分布式事務(wù)的場景

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

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

 

 

 

 

 

 

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

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

 

 

 

 

 

 

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

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

 

 

 

 

 

 

分布式事務(wù)解決方案

全局事務(wù)

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

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

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

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

整個事務(wù)分成兩個階段:

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

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

 

 

 

 

優(yōu)點：

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

缺點：

• 單點問題：事務(wù)協(xié)調(diào)者宕機

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

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

可靠消息服務(wù)

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

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

 

 

 

 

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

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

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

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

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

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

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

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

• 如果消息中間件收到確認應(yīng)答后便認為該事務(wù)處理完畢

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

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

最大努力通知

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

 

 

 

 

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

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

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

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

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

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

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

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

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

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

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

TCC事務(wù)

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

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

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

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

 

 

 

 

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

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

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

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

優(yōu)點：

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

缺點：

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

SAGA

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

 

 

 

 

補償協(xié)議：在Saga模式下，分布式事務(wù)內(nèi)有多個參與者，每個參與者都是正向補償服務(wù)。上圖中的 T1~Tn 就是 正向調(diào)用 ， C1~Cn 是 補償調(diào)用 ，正向調(diào)用和補償調(diào)用是一一對應(yīng)的關(guān)系。

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

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

Saga 模式使用場景

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

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

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

優(yōu)勢：

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

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

缺點：

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

SEATA

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

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

 

 

 

 

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

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

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

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

 

 

 

 

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

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

2. A服務(wù)的RM向TC注冊分支事務(wù)，并及其納入XID對應(yīng)全局事務(wù)的管轄

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

4. A服務(wù)開始遠程調(diào)用B服務(wù)，此時XID會在微服務(wù)的調(diào)用鏈上傳播

5. B服務(wù)的RM向TC注冊分支事務(wù)，并將其納入XID對應(yīng)的全局事務(wù)的管轄

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

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

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

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

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

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