[[409803]]

分布式事務基礎

事務

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

本地事務

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

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

C：一致性(Consistency) ，在一個事務執行之前和執行之后數據庫都必須處于一致性狀態

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

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

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

分布式事務

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

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

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

分布式事務的場景

• 單體系統訪問多個數據庫

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

 

 

 

 

 

 

• 多個微服務訪問同一個數據庫

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

 

 

 

 

 

 

• 多個微服務訪問多個數據庫

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

 

 

 

 

 

 

分布式事務解決方案

全局事務

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

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

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

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

整個事務分成兩個階段:

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

階段二: 執行階段，協調者根據所有參與者的反饋，通知所有參與者，步調一致地執行提交或者回滾。

 

 

 

 

優點：

• 提高了數據一致性的概率，實現成本較低

缺點：

• 單點問題：事務協調者宕機

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

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

可靠消息服務

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

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

 

 

 

 

第一步: 消息由系統A投遞到中間件

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

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

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

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

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

第二步: 消息由中間件投遞到系統B

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

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

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

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

最大努力通知

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

 

 

 

 

第一步: 消息由系統A投遞到中間件

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

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

第二步: 消息由中間件投遞到系統B

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

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

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

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

這種方式的優缺點：

優點：一種非常經典的實現，實現了最終一致性。

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

TCC事務

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

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

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

• Cancel：取消待執行的業務 取消Try階段預留的業務資源。

 

 

 

 

TCC兩階段提交與XA兩階段提交的區別是：

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

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

TCC事務的優缺點：

優點：

把數據庫層的二階段提交上提到了應用層來實現，規避了數據庫層的2PC性能低下問題。

缺點：

TCC的Try、Confirm和Cancel操作功能需業務提供，開發成本高。

SAGA

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

 

 

 

 

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

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

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

Saga 模式使用場景

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

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

Saga模式的優勢與缺點

優勢：

一階段提交本地數據庫事務，無鎖，高性能；

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

缺點：

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

SEATA

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

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

 

 

 

 

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

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

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

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

 

 

 

 

Seata的執行流程如下:

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

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

3. A服務執行分支事務，向數據庫做操作

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

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

6. B服務執行分支事務，向數據庫做操作

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

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

Seata實現2PC與傳統2PC的差別：

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

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