大廠面試必知必會(huì)：圖解分布式事務(wù)實(shí)現(xiàn)原理-創(chuàng)新互聯(lián)

問題場(chǎng)景

網(wǎng)站建設(shè)公司,為您提供網(wǎng)站建設(shè),網(wǎng)站制作,網(wǎng)頁設(shè)計(jì)及定制網(wǎng)站建設(shè)服務(wù),專注于成都企業(yè)網(wǎng)站定制,高端網(wǎng)頁制作,對(duì)成都陽光房等多個(gè)行業(yè)擁有豐富的網(wǎng)站建設(shè)經(jīng)驗(yàn)的網(wǎng)站建設(shè)公司。專業(yè)網(wǎng)站設(shè)計(jì),網(wǎng)站優(yōu)化推廣哪家好,專業(yè)成都網(wǎng)站推廣優(yōu)化,H5建站,響應(yīng)式網(wǎng)站。

什么是事務(wù)?

事務(wù)是數(shù)據(jù)庫從一個(gè)穩(wěn)定狀態(tài)變遷到另一個(gè)穩(wěn)定狀態(tài)的保證，具備 ACID 這 4 個(gè)特性：

• 原子性（Atomicity）：一個(gè)事務(wù)中的所有操作，要么全部完成，要么全部不完成，不會(huì)結(jié)束在中間某個(gè)環(huán)節(jié)。事務(wù)在執(zhí)行過程中發(fā)生錯(cuò)誤，會(huì)被回滾到事務(wù)開始前的狀態(tài)。

• 一致性（Consistency）：在事務(wù)開始之前和事務(wù)結(jié)束以后，數(shù)據(jù)庫的完整性限制沒有被破壞。

• 隔離性（Isolation）：兩個(gè)事務(wù)的執(zhí)行是互不干擾的，兩個(gè)事務(wù)時(shí)間不會(huì)互相影響。

• 持久性（Durability）：在事務(wù)完成以后，該事務(wù)對(duì)數(shù)據(jù)庫所作的更改便持久地保存在數(shù)據(jù)庫之中，并且是完全的。

例如應(yīng)用程序需要更新多條相關(guān)數(shù)據(jù)時(shí)就需要進(jìn)行事務(wù)處理。

什么是分布式事務(wù)?

當(dāng)遇到復(fù)雜業(yè)務(wù)調(diào)用時(shí)，可能會(huì)出現(xiàn)跨庫多資源調(diào)用(一個(gè)事務(wù)管理器，多個(gè)資源)/多服務(wù)調(diào)用（多個(gè)事務(wù)管理器，多個(gè)資源），期望全部成功或失敗回滾，這就是分布式事務(wù)，用以保證“操作多個(gè)隔離資源的數(shù)據(jù)一致性”。

分布式事務(wù)與 XA 規(guī)范

分布式事務(wù)是指會(huì)涉及到操作多個(gè)數(shù)據(jù)庫的事務(wù)，同樣必須保證 ACID。其就是將對(duì)同一庫事務(wù)的概念擴(kuò)大到了對(duì)多個(gè)庫的事務(wù)：對(duì)同一庫的 SQL 操作對(duì)應(yīng)了分布式事務(wù)中對(duì)一個(gè)庫的事務(wù)。

X/Open XA 定義了分布式事務(wù)處理的規(guī)范，并由數(shù)據(jù)庫廠商在驅(qū)動(dòng)層面進(jìn)行實(shí)現(xiàn)。XA 規(guī)范的基礎(chǔ)是兩階段提交協(xié)議，并定義了分布式事務(wù)處理所涉及的角色：

應(yīng)用程序（AP）
事務(wù)管理器（TM）
資源管理器（RM）
通信資源管理器（CRM）

常見的事務(wù)管理器（ TM ）是交易中間件，常見的資源管理器（ RM ）是數(shù)據(jù)庫，常見的通信資源管理器（ CRM ）是消息中間件。

可以這樣認(rèn)為，事務(wù)管理器即事務(wù)處理中間件（分布式事務(wù)處理系統(tǒng)）；資源管理器即各個(gè)數(shù)據(jù)庫。

兩階段提交協(xié)議

兩階段提交協(xié)議（Two-phase commit protocol, 2PC）將一次分布式事務(wù)處理劃分為兩個(gè)階段：預(yù)提交階段（也稱為準(zhǔn)備階段或投票階段），提交階段。

1 預(yù)提交階段

這是兩階段提交協(xié)議的第一個(gè)階段，分布式事務(wù)處理系統(tǒng)咨詢各個(gè)資源管理器是否可以提交本地事務(wù)，各個(gè)資源管理器會(huì)把這個(gè)咨詢過程寫入日志，以便進(jìn)行回滾或提交。

當(dāng)一個(gè)數(shù)據(jù)庫接收到咨詢后，它會(huì)將需要執(zhí)行的操作寫入日志，禁止其他寫入操作（鎖定資源）。

如果分布式事務(wù)中某數(shù)據(jù)庫預(yù)提交失敗或提交失敗，那該數(shù)據(jù)庫會(huì)根據(jù)日志進(jìn)行自身的操作回滾，并解鎖。

2 提交階段

分布式事務(wù)處理系統(tǒng)對(duì)各個(gè)資源管理器下達(dá)提交/回滾的指令，使整個(gè)分布式事務(wù)結(jié)束。

當(dāng)一個(gè)數(shù)據(jù)庫接受到提交/回滾指令時(shí)，它將根據(jù)第一階段的日志進(jìn)行提交/回滾處理。

兩階段提交協(xié)議可以在數(shù)據(jù)庫層面通過驅(qū)動(dòng)支持，也可以在應(yīng)用框架中按照其原理進(jìn)行設(shè)計(jì)實(shí)現(xiàn)。

兩階段提交協(xié)議（Two Phase Commitment Protocol）是分布式事務(wù)的基礎(chǔ)協(xié)議。

在此協(xié)議中，一個(gè)事務(wù)協(xié)調(diào)器（TM, transaction manager）協(xié)調(diào)多個(gè)資源管理器（RM, resource manager）的活動(dòng)；在一階段所有資源管理器（RM）向事務(wù)管理器（TM）匯報(bào)自身活動(dòng)狀態(tài)，在第二階段事務(wù)管理器（TM）根據(jù)各資源管理器（RM）匯報(bào)的狀態(tài)，來決定各RM是執(zhí)行提交操作還是回滾操作；具體描述如下：

1. 應(yīng)用程序向事務(wù)管理器（TM）提交請(qǐng)求，發(fā)起方分布式事務(wù)；

2. 一階段，事務(wù)管理器（TM）聯(lián)絡(luò)所有資源管理器（RM），通知它們執(zhí)行準(zhǔn)備操作；

3. 資源管理器（RM）返回準(zhǔn)備成功，或者失敗的消息給TM（響應(yīng)超時(shí)算作失?。?；

4. 二階段，如果所有RM均準(zhǔn)備成功，TM會(huì)通知所有RM執(zhí)行提交；如果任一RM準(zhǔn)備失敗，TM會(huì)通知所有RM回滾；

通過事務(wù)管理器2階段協(xié)調(diào)資源管理器，使所有資源管理器的狀態(tài)最終都是一致的，要么全部提交，要么全部回滾。

2PC應(yīng)用之XA

XA是X/Open組織提出的，定義了事務(wù)管理器與資源管理器之間通信的接口協(xié)議；XA協(xié)議由數(shù)據(jù)庫實(shí)現(xiàn)，目前支持XA協(xié)議的數(shù)據(jù)庫有Oracle、MySql、BD2等；

XA定義了一系列的接口：

• xa_start: 啟動(dòng)XA事務(wù)

• xa_end: 結(jié)束XA事務(wù)

• xa_prepare: 準(zhǔn)備階段，XA事務(wù)預(yù)提交

• xa_commit：提交XA事務(wù)

• xa_rollback: 回滾XA事務(wù)

一個(gè)數(shù)據(jù)庫實(shí)現(xiàn)XA協(xié)議之后，它就可以作為作為一個(gè)資源管理器參與到分布式事務(wù)中;

在一階段，事務(wù)管理器協(xié)調(diào)所有數(shù)據(jù)庫執(zhí)行XA事務(wù)（xa_start、用戶SQL、xa_end），并完成XA事務(wù)預(yù)提交（xa_prepare）；

在二階段，如果所有數(shù)據(jù)庫上XA事務(wù)預(yù)提交均成功，那么事務(wù)管理器協(xié)調(diào)所有數(shù)據(jù)庫提交XA事務(wù)（xa_commit）；如果任一數(shù)據(jù)庫上XA是我預(yù)提交失敗，那么事務(wù)管理器會(huì)協(xié)調(diào)所有數(shù)據(jù)組回滾XA事務(wù)（xa_rollback）;

分階段提交原理

分布式事物基本理論: 基本遵循CPA理論，采用柔性事物特征，軟狀態(tài)或者最終一致性特點(diǎn)保證分布式事物一致性問題。

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

1. 2PC兩段提交協(xié)議

2. 3PC三段提交協(xié)議(彌補(bǔ)兩端提交協(xié)議缺點(diǎn))

3. TCC或者GTS(阿里)

4. 消息中間件最終一致性

5. 使用LCN解決分布式事物，理念“LCN并不生產(chǎn)事務(wù),LCN只是本地事務(wù)的搬運(yùn)工”。

兩階段提交（2PC）

兩階段提交又稱2PC,2PC是一個(gè)非常經(jīng)典的強(qiáng)一致、中心化的原子提交協(xié)議。

這里所說的中心化是指協(xié)議中有兩類節(jié)點(diǎn)：一個(gè)是中心化協(xié)調(diào)者節(jié)點(diǎn)（coordinator）和N個(gè)參與者節(jié)點(diǎn)（partcipant）。

兩個(gè)階段：第一階段：投票階段?和第二階段：提交/執(zhí)行階段。

舉例?訂單服務(wù)A，需要調(diào)用?支付服務(wù)B?去支付，支付成功則處理購物訂單為待發(fā)貨狀態(tài)，否則就需要將購物訂單處理為失敗狀態(tài)。

那么看2PC階段是如何處理的

1、第一階段：投票階段

image

第一階段主要分為3步

1）事務(wù)詢問

協(xié)調(diào)者?向所有的?參與者?發(fā)送事務(wù)預(yù)處理請(qǐng)求，稱之為Prepare，并開始等待各?參與者?的響應(yīng)。

2）執(zhí)行本地事務(wù)

各個(gè)?參與者?節(jié)點(diǎn)執(zhí)行本地事務(wù)操作,但在執(zhí)行完成后并不會(huì)真正提交數(shù)據(jù)庫本地事務(wù)，而是先向?協(xié)調(diào)者?報(bào)告說：“我這邊可以處理了/我這邊不能處理”。.

3）各參與者向協(xié)調(diào)者反饋事務(wù)詢問的響應(yīng)

如果?參與者?成功執(zhí)行了事務(wù)操作,那么就反饋給協(xié)調(diào)者?Yes?響應(yīng),表示事務(wù)可以執(zhí)行,如果沒有?參與者?成功執(zhí)行事務(wù),那么就反饋給協(xié)調(diào)者?No?響應(yīng),表示事務(wù)不可以執(zhí)行。

第一階段執(zhí)行完后，會(huì)有兩種可能。1、所有都返回Yes. 2、有一個(gè)或者多個(gè)返回No。

2、第二階段：提交/執(zhí)行階段（成功流程）

成功條件：所有參與者都返回Yes。

第二階段主要分為兩步

1)所有的參與者反饋給協(xié)調(diào)者的信息都是Yes,那么就會(huì)執(zhí)行事務(wù)提交

協(xié)調(diào)者?向?所有參與者?節(jié)點(diǎn)發(fā)出Commit請(qǐng)求.

2)事務(wù)提交

參與者?收到Commit請(qǐng)求之后,就會(huì)正式執(zhí)行本地事務(wù)Commit操作,并在完成提交之后釋放整個(gè)事務(wù)執(zhí)行期間占用的事務(wù)資源。

第二階段：提交/執(zhí)行階段（異常流程）

異常條件：任何一個(gè)?參與者?向?協(xié)調(diào)者?反饋了?No?響應(yīng),或者等待超時(shí)之后,協(xié)調(diào)者尚未收到所有參與者的反饋響應(yīng)。

異常流程第二階段也分為兩步

1)發(fā)送回滾請(qǐng)求

協(xié)調(diào)者?向所有參與者節(jié)點(diǎn)發(fā)出?RoollBack?請(qǐng)求.

2)事務(wù)回滾

參與者?接收到RoollBack請(qǐng)求后,會(huì)回滾本地事務(wù)。

2PC缺點(diǎn)

通過上面的演示，很容易想到2pc所帶來的缺陷

1）性能問題

無論是在第一階段的過程中,還是在第二階段,所有的參與者資源和協(xié)調(diào)者資源都是被鎖住的,只有當(dāng)所有節(jié)點(diǎn)準(zhǔn)備完畢，事務(wù)?協(xié)調(diào)者?才會(huì)通知進(jìn)行全局提交，

參與者?進(jìn)行本地事務(wù)提交后才會(huì)釋放資源。這樣的過程會(huì)比較漫長(zhǎng)，對(duì)性能影響比較大。

2）單節(jié)點(diǎn)故障

由于協(xié)調(diào)者的重要性，一旦?協(xié)調(diào)者?發(fā)生故障。參與者?會(huì)一直阻塞下去。尤其在第二階段，協(xié)調(diào)者?發(fā)生故障，那么所有的?參與者?還都處于

鎖定事務(wù)資源的狀態(tài)中，而無法繼續(xù)完成事務(wù)操作。（雖然協(xié)調(diào)者掛掉，可以重新選舉一個(gè)協(xié)調(diào)者，但是無法解決因?yàn)閰f(xié)調(diào)者宕機(jī)導(dǎo)致的參與者處于阻塞狀態(tài)的問題）

2PC出現(xiàn)單點(diǎn)問題的三種情況

(1)協(xié)調(diào)者正常,參與者宕機(jī)

由于?協(xié)調(diào)者?無法收集到所有?參與者?的反饋，會(huì)陷入阻塞情況。

解決方案:引入超時(shí)機(jī)制,如果協(xié)調(diào)者在超過指定的時(shí)間還沒有收到參與者的反饋,事務(wù)就失敗,向所有節(jié)點(diǎn)發(fā)送終止事務(wù)請(qǐng)求。

(2)協(xié)調(diào)者宕機(jī),參與者正常

無論處于哪個(gè)階段，由于協(xié)調(diào)者宕機(jī)，無法發(fā)送提交請(qǐng)求，所有處于執(zhí)行了操作但是未提交狀態(tài)的參與者都會(huì)陷入阻塞情況.

解決方案:引入?yún)f(xié)調(diào)者備份,同時(shí)協(xié)調(diào)者需記錄操作日志.當(dāng)檢測(cè)到協(xié)調(diào)者宕機(jī)一段時(shí)間后，協(xié)調(diào)者備份取代協(xié)調(diào)者，并讀取操作日志，向所有參與者詢問狀態(tài)。

(3)協(xié)調(diào)者和參與者都宕機(jī)

1. 發(fā)生在第一階段：因?yàn)榈谝浑A段，所有參與者都沒有真正執(zhí)行commit，所以只需重新在剩余的參與者中重新選出一個(gè)協(xié)調(diào)者，新的協(xié)調(diào)者在重新執(zhí)行第一階段和第二階段就可以了。

2)發(fā)生在第二階段 并且 掛了的參與者在掛掉之前沒有收到協(xié)調(diào)者的指令。也就是上面的第4步掛了，這是可能協(xié)調(diào)者還沒有發(fā)送第4步就掛了。這種情形下，新的協(xié)調(diào)者重新執(zhí)行第一階段和第二階段操作。

3)發(fā)生在第二階段 并且 有部分參與者已經(jīng)執(zhí)行完commit操作。就好比這里訂單服務(wù)A和支付服務(wù)B都收到協(xié)調(diào)者?發(fā)送的commit信息，開始真正執(zhí)行本地事務(wù)commit,但突發(fā)情況，Acommit成功，B確掛了。這個(gè)時(shí)候目前來講數(shù)據(jù)是不一致的。雖然這個(gè)時(shí)候可以再通過手段讓他和協(xié)調(diào)者通信，再想辦法把數(shù)據(jù)搞成一致的，但是，這段時(shí)間內(nèi)他的數(shù)據(jù)狀態(tài)已經(jīng)是不一致的了！2PC 無法解決這個(gè)問題。

三階段提交(3PC)

三階段提交協(xié)議（3PC）主要是為了解決兩階段提交協(xié)議的阻塞問題，2pc存在的問題是當(dāng)協(xié)作者崩潰時(shí)，參與者不能做出最后的選擇。因此參與者可能在協(xié)作者恢復(fù)之前保持阻塞。

三階段提交（Three-phase commit），是二階段提交（2PC）的改進(jìn)版本。

與兩階段提交不同的是，三階段提交有兩個(gè)改動(dòng)點(diǎn)。

1、 引入超時(shí)機(jī)制。同時(shí)在協(xié)調(diào)者和參與者中都引入超時(shí)機(jī)制。
2、在第一階段和第二階段中插入一個(gè)準(zhǔn)備階段。保證了在最后提交階段之前各參與節(jié)點(diǎn)的狀態(tài)是一致的。

也就是說，除了引入超時(shí)機(jī)制之外，3PC把2PC的準(zhǔn)備階段再次一分為二，這樣三階段提交就有

CanCommit、PreCommit、DoCommit

三個(gè)階段。

1、CanCommit階段

之前2PC的一階段是本地事務(wù)執(zhí)行結(jié)束后，最后不Commit,等其它服務(wù)都執(zhí)行結(jié)束并返回Yes，由協(xié)調(diào)者發(fā)生commit才真正執(zhí)行commit。而這里的CanCommit指的是?嘗試獲取數(shù)據(jù)庫鎖?如果可以，就返回Yes。

這階段主要分為2步

事務(wù)詢問?協(xié)調(diào)者?向?參與者?發(fā)送CanCommit請(qǐng)求。詢問是否可以執(zhí)行事務(wù)提交操作。然后開始等待?參與者?的響應(yīng)。
響應(yīng)反饋?參與者?接到CanCommit請(qǐng)求之后，正常情況下，如果其自身認(rèn)為可以順利執(zhí)行事務(wù)，則返回Yes響應(yīng)，并進(jìn)入預(yù)備狀態(tài)。否則反饋No

2、PreCommit階段

在階段一中，如果所有的參與者都返回Yes的話，那么就會(huì)進(jìn)入PreCommit階段進(jìn)行事務(wù)預(yù)提交。這里的PreCommit階段?跟上面的第一階段是差不多的，只不過這里?協(xié)調(diào)者和參與者都引入了超時(shí)機(jī)制?（2PC中只有協(xié)調(diào)者可以超時(shí)，參與者沒有超時(shí)機(jī)制）。

3、DoCommit階段

這里跟2pc的階段二是差不多的。

總結(jié)

相比較2PC而言，3PC對(duì)于協(xié)調(diào)者（Coordinator）和參與者（Partcipant）都設(shè)置了超時(shí)時(shí)間，而2PC只有協(xié)調(diào)者才擁有超時(shí)機(jī)制。這解決了一個(gè)什么問題呢？

這個(gè)優(yōu)化點(diǎn)，主要是避免了參與者在長(zhǎng)時(shí)間無法與協(xié)調(diào)者節(jié)點(diǎn)通訊（協(xié)調(diào)者掛掉了）的情況下，無法釋放資源的問題，因?yàn)閰⑴c者自身擁有超時(shí)機(jī)制會(huì)在超時(shí)后，

自動(dòng)進(jìn)行本地commit從而進(jìn)行釋放資源。而這種機(jī)制也側(cè)面降低了整個(gè)事務(wù)的阻塞時(shí)間和范圍。

另外，通過CanCommit、PreCommit、DoCommit三個(gè)階段的設(shè)計(jì)，相較于2PC而言，多設(shè)置了一個(gè)緩沖階段保證了在最后提交階段之前各參與節(jié)點(diǎn)的狀態(tài)是一致的。

以上就是3PC相對(duì)于2PC的一個(gè)提高（相對(duì)緩解了2PC中的前兩個(gè)問題），但是3PC依然沒有完全解決數(shù)據(jù)不一致的問題。

2PC / 3PC / XA

TCC ( Try、Confirm、Cancel ) 原理

概念

TCC三個(gè)操作描述：

Try: 檢測(cè)、預(yù)留資源;
Confirm: 業(yè)務(wù)系統(tǒng)執(zhí)行提交；默認(rèn)Confirm階段是不會(huì)出錯(cuò)的，只要TRY成功，CONFIRM一定成功；
Cancel: 業(yè)務(wù)取消，預(yù)留資源釋放;

TCC又稱補(bǔ)償事務(wù)。其核心思想是："針對(duì)每個(gè)操作都要注冊(cè)一個(gè)與其對(duì)應(yīng)的確認(rèn)和補(bǔ)償（撤銷操作）"。它分為三個(gè)操作：

1、Try階段：主要是對(duì)業(yè)務(wù)系統(tǒng)做檢測(cè)及資源預(yù)留。
2、Confirm階段：確認(rèn)執(zhí)行業(yè)務(wù)操作。
3、Cancel階段：取消執(zhí)行業(yè)務(wù)操作。

TCC對(duì)應(yīng)?Try、Confirm、Cancel?三種操作可以理解成關(guān)系型數(shù)據(jù)庫事務(wù)的三種操作：DML、Commit、Rollback。

在一個(gè)跨應(yīng)用的業(yè)務(wù)操作中

Try：Try操作是先把多個(gè)應(yīng)用中的業(yè)務(wù)資源預(yù)留和鎖定住，為后續(xù)的確認(rèn)打下基礎(chǔ)，類似的，DML操作要鎖定數(shù)據(jù)庫記錄行，持有數(shù)據(jù)庫資源。

Confirm：Confirm操作是在Try操作中涉及的所有應(yīng)用均成功之后進(jìn)行確認(rèn)，使用預(yù)留的業(yè)務(wù)資源，和Commit類似；

Cancel：Cancel則是當(dāng)Try操作中涉及的所有應(yīng)用沒有全部成功，需要將已成功的應(yīng)用進(jìn)行取消(即Rollback回滾)。其中Confirm和Cancel操作是一對(duì)反向業(yè)務(wù)操作。

TCC的具體原理圖如（盜圖）:

從圖中我們可以明顯看到Confirm和Cancel操作是一對(duì)反向業(yè)務(wù)操作?即要try返回成功執(zhí)行Confirm,要么try返回失敗執(zhí)行Cancel操作。

分布式事務(wù)協(xié)調(diào)者：分布式事務(wù)協(xié)調(diào)者管理控制整個(gè)業(yè)務(wù)活動(dòng)，包括記錄維護(hù)TCC全局事務(wù)的事務(wù)狀態(tài)和每個(gè)從業(yè)務(wù)服務(wù)的子事務(wù)狀態(tài)，并在業(yè)務(wù)活動(dòng)提交時(shí)確認(rèn)所有的TCC型

操作的confirm操作，在業(yè)務(wù)活動(dòng)取消時(shí)調(diào)用所有TCC型操作的cancel操作。

舉例

例子：A服務(wù)轉(zhuǎn)30塊錢、B服務(wù)轉(zhuǎn)50塊錢，一起到C服務(wù)上。

Try：嘗試執(zhí)行業(yè)務(wù)。完成所有業(yè)務(wù)檢查(一致性)：檢查A、B、C的帳戶狀態(tài)是否正常，帳戶A的余額是否不少于30元，帳戶B的余額是否不少于50元。預(yù)留必須業(yè)務(wù)資源

(準(zhǔn)隔離性)：帳戶A的凍結(jié)金額增加30元，帳戶B的凍結(jié)金額增加50元，這樣就保證不會(huì)出現(xiàn)其他并發(fā)進(jìn)程扣減了這兩個(gè)帳戶的余額而導(dǎo)致在后續(xù)的真正轉(zhuǎn)帳操作過程中，

帳戶A和B的可用余額不夠的情況。

Confirm：確認(rèn)執(zhí)行業(yè)務(wù)。真正執(zhí)行業(yè)務(wù)：如果Try階段帳戶A、B、C狀態(tài)正常，且?guī)鬉、B余額夠用，則執(zhí)行帳戶A給賬戶C轉(zhuǎn)賬30元、帳戶B給賬戶C轉(zhuǎn)賬50元的轉(zhuǎn)帳

操作。?這時(shí)已經(jīng)不需要做任何業(yè)務(wù)檢查，Try階段已經(jīng)完成了業(yè)務(wù)檢查。只使用Try階段預(yù)留的業(yè)務(wù)資源：只需要使用Try階段帳戶A和帳戶B凍結(jié)的金額即可。

Cancel：取消執(zhí)行業(yè)務(wù)釋放Try階段預(yù)留的業(yè)務(wù)資源：如果Try階段部分成功，比如帳戶A的余額夠用，且凍結(jié)相應(yīng)金額成功，帳戶B的余額不夠而凍結(jié)失敗，則需要

對(duì)帳戶A做Cancel操作，將帳戶A被凍結(jié)的金額解凍掉。

TCC和2PC比較

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

XA事務(wù)中的兩階段提交內(nèi)部過程是對(duì)開發(fā)者屏蔽的，事務(wù)管理器在兩階段提交過程中，從prepare到commit/rollback過程中，資源實(shí)際上一直都是被加鎖的。

如果有其他人需要更新這兩條記錄，那么就必須等待鎖釋放。

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

我的理解就是當(dāng)執(zhí)行try接口的時(shí)候，已經(jīng)把所需的資源給預(yù)扣了，比如上面舉例的A服務(wù)已經(jīng)預(yù)扣30元，B服務(wù)已經(jīng)預(yù)扣50元，它是由try接口實(shí)現(xiàn)，這樣就保證不會(huì)

出現(xiàn)其他并發(fā)進(jìn)程扣減了這兩個(gè)帳戶的余額而導(dǎo)致在后續(xù)的真正轉(zhuǎn)帳操作過程中，帳戶A和B的可用余額不夠的情況，同時(shí)保證不會(huì)一直鎖住整個(gè)資源。（核心點(diǎn)應(yīng)該就在這）

TCC中的兩階段提交并沒有對(duì)開發(fā)者完全屏蔽，也就是說從代碼層面，開發(fā)者是可以感受到兩階段提交的存在。

1、try過程的本地事務(wù)，是保證資源預(yù)留的業(yè)務(wù)邏輯的正確性。

2、confirm/cancel執(zhí)行的本地事務(wù)邏輯確認(rèn)/取消預(yù)留資源，以保證最終一致性，也就是所謂的補(bǔ)償型事務(wù)。

由于是多個(gè)獨(dú)立的本地事務(wù)，因此不會(huì)對(duì)資源一直加鎖。

TCC 實(shí)質(zhì)上是應(yīng)用層的2PC ，好比把 XA 兩階段提交那種在數(shù)據(jù)資源層做的事務(wù)管理工作提到了數(shù)據(jù)應(yīng)用層。

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

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

TCC相比較于2PC來講性能會(huì)好很多，但是因?yàn)橥瑫r(shí)需要改造try、confirm、canel3個(gè)接口，開發(fā)成本高。

注意:還有一點(diǎn)需要注意的是Confirm和Cancel操作可能被重復(fù)調(diào)用，故要求Confirm和Cancel兩個(gè)接口必須是冪等。

RocketMQ 分布式事務(wù)原理

一、舉個(gè)分布式事務(wù)場(chǎng)景

列子：假設(shè)?A?給?B?轉(zhuǎn)?100塊錢，同時(shí)它們不是同一個(gè)服務(wù)上。

目標(biāo)：就是?A?減100塊錢，B?加100塊錢。

實(shí)際情況可能有四種：

1）就是A賬戶減100 （成功），B賬戶加100 （成功）2）就是A賬戶減100（失?。?，B賬戶加100 （失?。?）就是A賬戶減100（成功），B賬戶加100 （失?。?）就是A賬戶減100 （失敗），B賬戶加100 （成功）

這里?第1和第2?種情況是能夠保證事務(wù)的一致性的，但是?第3和第4?是無法保證事務(wù)的一致性的。

柔性事務(wù)

單數(shù)據(jù)庫事務(wù)完全遵循ACID規(guī)范，屬于剛性事務(wù)，分布式事務(wù)要完全遵循ACID規(guī)范比較困難, 分布式事務(wù)屬于柔性事務(wù)，滿足BASE理論；

BASE描述：BA（Basic Availability 基本業(yè)務(wù)可用性）、S（Soft state 柔性狀態(tài)）、E（Eventual consistency 最終一致性）；

柔性事務(wù)對(duì)ACID的支持：

1、原子性：嚴(yán)格遵循；

2、一致性：事務(wù)完成后的一致性嚴(yán)格遵循，事務(wù)中的一致性可適當(dāng)放寬；

3、隔離性：并行事務(wù)間不可影響；事務(wù)中間結(jié)果可見性允許安全放寬；

4、持久性：嚴(yán)格遵循

為了可用性、性能的需要，柔性事務(wù)降低了一致性(C)與隔離性(I) 的要求，即“基本可用，最終一致”.

那我們來看下RocketMQ是如何來保證事務(wù)的一致性的。

RocketMQ 實(shí)現(xiàn)分布式事務(wù)原理

RocketMQ雖然之前也支持分布式事務(wù)，但并沒有開源，等到RocketMQ 4.3才正式開源。

1、基礎(chǔ)概念

最終一致性

RocketMQ是一種最終一致性的分布式事務(wù)，就是說它保證的是消息最終一致性，而不是像2PC、3PC、TCC那樣強(qiáng)一致分布式事務(wù)，至于為什么說它是最終一致性事務(wù)下面會(huì)詳細(xì)說明。

Half Message(半消息)

是指暫不能被Consumer消費(fèi)的消息。Producer 已經(jīng)把消息成功發(fā)送到了 Broker 端，但此消息被標(biāo)記為暫不能投遞狀態(tài)，處于該種狀態(tài)下的消息稱為半消息。需要 Producer

對(duì)消息的二次確認(rèn)后，Consumer才能去消費(fèi)它。

消息回查

由于網(wǎng)絡(luò)閃段，生產(chǎn)者應(yīng)用重啟等原因。導(dǎo)致 Producer 端一直沒有對(duì)?Half Message(半消息)?進(jìn)行?二次確認(rèn)。這是Brock服務(wù)器會(huì)定時(shí)掃描長(zhǎng)期處于半消息的消息，會(huì)

主動(dòng)詢問 Producer端 該消息的最終狀態(tài)(Commit或者Rollback),該消息即為?消息回查。

2、分布式事務(wù)交互流程

理解這張阿里官方的圖，就能理解RocketMQ分布式事務(wù)的原理了。

我們來說明下上面這張圖

1、A服務(wù)先發(fā)送個(gè)Half Message給Brock端，消息中攜帶 B服務(wù) 即將要+100元的信息。
2、當(dāng)A服務(wù)知道Half Message發(fā)送成功后，那么開始第3步執(zhí)行本地事務(wù)。
3、執(zhí)行本地事務(wù)(會(huì)有三種情況1、執(zhí)行成功。2、執(zhí)行失敗。3、網(wǎng)絡(luò)等原因?qū)е聸]有響應(yīng))
4.1)、如果本地事務(wù)成功，那么Product像Brock服務(wù)器發(fā)送Commit,這樣B服務(wù)就可以消費(fèi)該message。4.2)、如果本地事務(wù)失敗，那么Product像Brock服務(wù)器發(fā)送Rollback,那么就會(huì)直接刪除上面這條半消息。4.3)、如果因?yàn)榫W(wǎng)絡(luò)等原因遲遲沒有返回失敗還是成功，那么會(huì)執(zhí)行RocketMQ的回調(diào)接口,來進(jìn)行事務(wù)的回查。

從上面流程可以得知?只有A服務(wù)本地事務(wù)執(zhí)行成功 ，B服務(wù)才能消費(fèi)該message。

然后我們?cè)賮硭伎紟讉€(gè)問題？

為什么要先發(fā)送Half Message(半消息)

我覺得主要有兩點(diǎn)

1）可以先確認(rèn) Brock服務(wù)器是否正常 ，如果半消息都發(fā)送失敗了 那說明Brock掛了。
2）可以通過半消息來回查事務(wù)，如果半消息發(fā)送成功后一直沒有被二次確認(rèn)，那么就會(huì)回查事務(wù)狀態(tài)。

什么情況會(huì)回查

也會(huì)有兩種情況

1）執(zhí)行本地事務(wù)的時(shí)候，由于突然網(wǎng)絡(luò)等原因一直沒有返回執(zhí)行事務(wù)的結(jié)果(commit或者rollback)導(dǎo)致最終返回UNKNOW，那么就會(huì)回查。
2) 本地事務(wù)執(zhí)行成功后，返回Commit進(jìn)行消息二次確認(rèn)的時(shí)候的服務(wù)掛了，在重啟服務(wù)那么這個(gè)時(shí)候在brock端   它還是個(gè)Half Message(半消息)，這也會(huì)回查。

特別注意: 如果回查，那么一定要先查看當(dāng)前事務(wù)的執(zhí)行情況，再看是否需要重新執(zhí)行本地事務(wù)。

想象下如果出現(xiàn)第二種情況而引起的回查，如果不先查看當(dāng)前事務(wù)的執(zhí)行情況，而是直接執(zhí)行事務(wù)，那么就相當(dāng)于成功執(zhí)行了兩個(gè)本地事務(wù)。

為什么說MQ是最終一致性事務(wù)

通過上面這幅圖，我們可以看出，在上面舉例事務(wù)不一致的兩種情況中，永遠(yuǎn)不會(huì)發(fā)生

A賬戶減100 （失?。?，B賬戶加100 （成功）

因?yàn)椋喝绻鸄服務(wù)本地事務(wù)都失敗了，那B服務(wù)永遠(yuǎn)不會(huì)執(zhí)行任何操作，因?yàn)橄焊筒粫?huì)傳到B服務(wù)。

那么?A賬戶減100 （成功），B賬戶加100 （失?。?會(huì)不會(huì)可能存在的。

答案是會(huì)的

因?yàn)锳服務(wù)只負(fù)責(zé)當(dāng)我消息執(zhí)行成功了，保證消息能夠送達(dá)到B,至于B服務(wù)接到消息后最終執(zhí)行結(jié)果A并不管。

那B服務(wù)失敗怎么辦？

如果B最終執(zhí)行失敗，幾乎可以斷定就是代碼有問題所以才引起的異常，因?yàn)橄M(fèi)端RocketMQ有重試機(jī)制，如果不是代碼問題一般重試幾次就能成功。

如果是代碼的原因引起多次重試失敗后，也沒有關(guān)系，將該異常記錄下來，由人工處理，人工兜底處理后，就可以讓事務(wù)達(dá)到最終的一致性。

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務(wù)器15元起步，三天無理由+7*72小時(shí)售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國(guó)服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡(jiǎn)單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢(shì)，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場(chǎng)景需求。

網(wǎng)頁題目：大廠面試必知必會(huì)：圖解分布式事務(wù)實(shí)現(xiàn)原理-創(chuàng)新互聯(lián)
地址分享：http://www.muchs.cn/article6/dgiiog.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供自適應(yīng)網(wǎng)站、網(wǎng)站營(yíng)銷、ChatGPT、移動(dòng)網(wǎng)站建設(shè)、面包屑導(dǎo)航、網(wǎng)站策劃

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)