[[409803]]

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

事務(wù)

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

本地事務(wù)

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

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

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

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

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

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

分布式事務(wù)

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

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

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

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

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

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

 

 

 

 

 

 

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

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

 

 

 

 

 

 

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

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

 

 

 

 

 

 

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

全局事務(wù)

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

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

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

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

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

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

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

 

 

 

 

優(yōu)點(diǎn)：

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

缺點(diǎn)：

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

• 同步阻塞: 延遲了提交時(shí)間，加長(zhǎng)了資源阻塞時(shí)間

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

可靠消息服務(wù)

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

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

 

 

 

 

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

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

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

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

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

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

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

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

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

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

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

最大努力通知

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

 

 

 

 

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

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

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

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

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

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

3. 對(duì)于投遞失敗的消息，利用重試機(jī)制進(jìn)行重試，對(duì)于重試失敗的，寫入錯(cuò)誤消息表

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

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

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

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

TCC事務(wù)

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

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

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

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

 

 

 

 

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

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

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

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

優(yōu)點(diǎn)：

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

缺點(diǎn)：

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

SAGA

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

 

 

 

 

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

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

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

Saga 模式使用場(chǎng)景

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

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

Saga模式的優(yōu)勢(shì)與缺點(diǎn)

優(yōu)勢(shì)：

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

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

缺點(diǎn)：

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

SEATA

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

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

 

 

 

 

Seata主要由三個(gè)重要組件組成：

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

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

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

 

 

 

 

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

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

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

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

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

5. B服務(wù)的RM向TC注冊(cè)分支事務(wù)，并將其納入XID對(duì)應(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實(shí)現(xiàn)2PC與傳統(tǒng)2PC的差別：

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

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