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

答：指一次大的操作由不同的小操作組成的，這些小的操作分布在不同的服務(wù)器上，分布式事務(wù)需要保證這些小操作要么全部成功，要么全部失敗。從本質(zhì)上來(lái)說(shuō)，分布式事務(wù)就是為了保證不同數(shù)據(jù)庫(kù)的數(shù)據(jù)一致性。

分布式事務(wù)產(chǎn)生的原因?

1 數(shù)據(jù)庫(kù)分庫(kù)分表

當(dāng)數(shù)據(jù)庫(kù)單表數(shù)據(jù)達(dá)到千萬(wàn)級(jí)別，就要考慮分庫(kù)分表，那么就會(huì)從原來(lái)的一個(gè)數(shù)據(jù)庫(kù)變成多個(gè)數(shù)據(jù)庫(kù)。例如如果一個(gè)操作即操作了01庫(kù)，又操作了02庫(kù)，而且又要保證數(shù)據(jù)的一致性，那么就要用到分布式事務(wù)。

2 應(yīng)用SOA化

所謂的SOA化，就是業(yè)務(wù)的服務(wù)化。例如電商平臺(tái)下單操作就會(huì)產(chǎn)生調(diào)用庫(kù)存服務(wù)扣減庫(kù)存和訂單服務(wù)更新訂單數(shù)據(jù)，那么就會(huì)設(shè)計(jì)到訂單數(shù)據(jù)庫(kù)和庫(kù)存數(shù)據(jù)庫(kù)，為了保證數(shù)據(jù)的一致性，就需要用到分布式事務(wù)。

總結(jié)：其實(shí)上面兩種場(chǎng)景，歸根到底是要操作多數(shù)據(jù)庫(kù)，并且要保證數(shù)據(jù)的一致性，而產(chǎn)生的分布式事務(wù)的。

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

1、兩階段提交(2PC)

XA是一個(gè)分布式事務(wù)協(xié)議，由Tuxedo提出。XA中大致分為兩部分：事務(wù)管理器和本地資源管理器。其中本地資源管理器往往由數(shù)據(jù)庫(kù)實(shí)現(xiàn)，比如Oracle、Mysql等數(shù)據(jù)庫(kù)都實(shí)現(xiàn)了XA接口，而事務(wù)管理器作為全局的調(diào)度者，負(fù)責(zé)各個(gè)本地資源的提交回滾。

XA實(shí)現(xiàn)分布式事務(wù)的原理如下：

總結(jié)

二階段提交看起來(lái)確實(shí)能夠提供原子性的操作，但是它存在幾個(gè)缺點(diǎn)：

• 同步阻塞問(wèn)題：執(zhí)行過(guò)程中，所有參與節(jié)點(diǎn)都是事務(wù)阻塞型的。當(dāng)參與者占有公共資源時(shí)，其他第三方節(jié)點(diǎn)訪問(wèn)公共資源不得不處于阻塞狀態(tài)。
• 單點(diǎn)故障：由于(事務(wù)管理器)協(xié)調(diào)者的重要性，一旦協(xié)調(diào)者發(fā)生故障。(本地資源管理器)參與者會(huì)一直阻塞下去。尤其在第二階段，協(xié)調(diào)者發(fā)生故障，那么所有的參與者還都處于鎖定事務(wù)資源的狀態(tài)中，而無(wú)法繼續(xù)完成事務(wù)操作。(如果是協(xié)調(diào)者掛掉，可以重新選舉一個(gè)協(xié)調(diào)者，但是無(wú)法解決因?yàn)閰f(xié)調(diào)者宕機(jī)導(dǎo)致的參與者處于阻塞狀態(tài)的問(wèn)題)
• 數(shù)據(jù)不一致：在二階段提交的階段二中，當(dāng)協(xié)調(diào)者向參與者發(fā)送commit請(qǐng)求之后，發(fā)生了局部網(wǎng)絡(luò)異常或者在發(fā)送commit請(qǐng)求過(guò)程中協(xié)調(diào)者發(fā)生了故障，這會(huì)導(dǎo)致只有一部分參與者接收到了commit請(qǐng)求。而在這部分參與者接到commit請(qǐng)求之后就會(huì)執(zhí)行commit操作。但是其他部分未接到commit請(qǐng)求的機(jī)器無(wú)法執(zhí)行事務(wù)提交。于是整個(gè)分布式系統(tǒng)便出現(xiàn)了數(shù)據(jù)不一致的現(xiàn)象。
• 二階段無(wú)法解決的問(wèn)題：參與者在發(fā)出commit消息之后宕機(jī)，而唯一接收到這條消息的協(xié)調(diào)者同時(shí)也宕機(jī)了。那么即使協(xié)調(diào)者通過(guò)選舉協(xié)議產(chǎn)生了新的協(xié)調(diào)者，這條事務(wù)的狀態(tài)也是不確定的，沒(méi)人知道事務(wù)是否被已經(jīng)提交了。

2、三階段提交(3PC)

3PC其實(shí)在2PC的基礎(chǔ)上增加了CanCommit階段，是2PC的變種，并引入了超時(shí)機(jī)制。一旦事務(wù)參與者遲遲沒(méi)有收到協(xié)調(diào)者的Commit請(qǐng)求，就會(huì)自動(dòng)進(jìn)行本地commit，這樣相對(duì)有效的解決了協(xié)調(diào)者單點(diǎn)故障的問(wèn)題。但是，性能和數(shù)據(jù)一致性問(wèn)題沒(méi)有根本解決。

3PC分為三個(gè)階段：CanCommit、PreCommit、DoCommit

CanCommit階段

它跟2PC的 準(zhǔn)備階段很像，協(xié)調(diào)者向參與者發(fā)送commit請(qǐng)求，參與者如果可以提交就返回Yes響應(yīng)，否則返回No響應(yīng)。

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

PreCommit階段

協(xié)調(diào)者根據(jù)參與者的響應(yīng)情況來(lái)決定是否可以進(jìn)行事務(wù)的PreCommit操作。根據(jù)響應(yīng)情況，有以下兩種可能：

• 假如協(xié)調(diào)者從所有的參與者獲得的反饋都是Yes，那么就會(huì)執(zhí)行事務(wù)的與執(zhí)行。
• 發(fā)送預(yù)提交請(qǐng)求：協(xié)調(diào)者向參與者發(fā)送PreCommit請(qǐng)求，并進(jìn)入Prepared階段。
• 事務(wù)預(yù)提交：參與者接收到PreCommit請(qǐng)求后，會(huì)執(zhí)行事務(wù)操作，并將undo和redo信息記錄到事務(wù)日志中。
• 響應(yīng)反饋：如果參與者成功的執(zhí)行了事務(wù)操作，則返回ACK響應(yīng)，同時(shí)開始等待最終指令。
• 假如有任何一個(gè)參與者向協(xié)調(diào)者發(fā)送了No響應(yīng)，或者等待超時(shí)，或者協(xié)調(diào)者都沒(méi)有接到參與者的響應(yīng)，那么就執(zhí)行事務(wù)的中斷。
• 發(fā)送中斷請(qǐng)求：協(xié)調(diào)者向所有參與者發(fā)送abort請(qǐng)求。
• 中斷事務(wù)：參與者收到來(lái)自協(xié)調(diào)者的abort請(qǐng)求之后(或超時(shí)之后，仍未收到協(xié)調(diào)者的請(qǐng)求)，執(zhí)行事務(wù)的中斷。

doCommit階段

該階段進(jìn)行真正的事務(wù)提交，也可以分為以下兩種情況：

• 執(zhí)行提交
• 發(fā)送提交請(qǐng)求：協(xié)調(diào)接收到參與者發(fā)送的ACK響應(yīng)，那么將從預(yù)提交狀態(tài)進(jìn)入到提交狀態(tài)。并向所有參與者發(fā)送doCommit請(qǐng)求。
• 事務(wù)提交：參與者接收到doCommit請(qǐng)求之后，執(zhí)行正式的事務(wù)提交，并在完成事務(wù)提交之后釋放所有事務(wù)資源。
• 響應(yīng)反饋：事務(wù)提交完之后，向協(xié)調(diào)者發(fā)送ACK響應(yīng)。
• 完成事務(wù)：協(xié)調(diào)者接收到所有參與者的ACK響應(yīng)之后，完成事務(wù)。
• 中斷事務(wù)
• 協(xié)調(diào)者沒(méi)有接收到參與者發(fā)送的ACK響應(yīng)(可能是接受者發(fā)送的不是ACK響應(yīng)，也可能響應(yīng)超時(shí))，那么就會(huì)執(zhí)行中斷事務(wù)。
• 發(fā)送中斷請(qǐng)求：協(xié)調(diào)者向所有參與者發(fā)送abort請(qǐng)求
• 事務(wù)回滾：參與者接收到abort請(qǐng)求之后，利用其在階段二記錄的undo信息來(lái)執(zhí)行事務(wù)的回滾操作，并在完成回滾之后釋放所有的事務(wù)資源。
• 反饋結(jié)果：參與者完成事務(wù)回滾之后，像協(xié)調(diào)者發(fā)送ACK消息。
• 中斷事務(wù)：協(xié)調(diào)者接收到參與者反饋的ACK消息之后，執(zhí)行事務(wù)的中斷。

原理圖如下：

總結(jié)

相對(duì)于2PC而言，3PC對(duì)于協(xié)調(diào)者和參與者都設(shè)置了超時(shí)時(shí)間，而2PC只有協(xié)調(diào)者才擁有超時(shí)時(shí)間機(jī)制。這個(gè)優(yōu)化解決了，參與者在長(zhǎng)時(shí)間無(wú)法與協(xié)調(diào)者節(jié)點(diǎn)通訊的情況下，無(wú)法釋放資源的問(wèn)題，因?yàn)閰⑴c者自身?yè)碛谐瑫r(shí)機(jī)制會(huì)在超時(shí)后，自動(dòng)進(jìn)行本地commit從而進(jìn)行釋放資源。而這種機(jī)制也側(cè)面降低了整個(gè)事務(wù)的阻塞時(shí)間和范圍。但是仍然沒(méi)有解決數(shù)據(jù)一致性問(wèn)題，即在參與者收到PreCommit請(qǐng)求后等待最終指令，如果此時(shí)協(xié)調(diào)者無(wú)法與參與者正常通信，會(huì)導(dǎo)致參與者繼續(xù)提交事務(wù)，造成數(shù)據(jù)不一致。

3、補(bǔ)償事務(wù)(TCC)

TCC(Try-Confirm-Cancel)又稱補(bǔ)償事務(wù)。它實(shí)際上與2PC、3PC一樣，都是分布式事務(wù)的一種實(shí)現(xiàn)方案而已。它分為三個(gè)操作：

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

TCC事務(wù)的處理流程與2PC兩階段提交類似，不過(guò)2PC通常都是在DB層面，而TCC本質(zhì)上就是應(yīng)用層面的2PC，需要通過(guò)業(yè)務(wù)邏輯來(lái)實(shí)現(xiàn)。它的優(yōu)勢(shì)在于，可以讓應(yīng)用自己定義數(shù)據(jù)庫(kù)操作的粒度，使得降低鎖沖突、提交吞吐量。

不過(guò)對(duì)應(yīng)用的侵入性非常強(qiáng)，業(yè)務(wù)邏輯的每個(gè)分支都需要實(shí)現(xiàn)try、confirm、cancel三個(gè)操作。

TCC原理圖如下：

4、消息事務(wù)+最終一致性

所謂的消息事務(wù)就是基于消息中間件的兩階段提交，本質(zhì)上是中間件的一種特殊利用，他是將本地事務(wù)和發(fā)消息放在一個(gè)分布式事務(wù)里，保證要么本地操作成功并且對(duì)外發(fā)消息成功，要么兩者都失敗，開源的RocketMQ就支持這一特性，具體原理如下：

步驟如下：

1. 服務(wù)A向消息中間件發(fā)送一條預(yù)備消息。
2. 消息中間件保存預(yù)備消息并返回成功。
3. 服務(wù)A執(zhí)行本地事務(wù)。
4. 服務(wù)A發(fā)送提交消息給消息中間件，服務(wù)B接收到消息之后執(zhí)行本地事務(wù)。

基于消息中間件的兩階段提交往往用在高并發(fā)場(chǎng)景下，將一個(gè)分布式事務(wù)拆成一個(gè)消息事務(wù)(服務(wù)A的本地操作+發(fā)消息)+服務(wù)B的本地操作，其中服務(wù)B的操作由消息驅(qū)動(dòng)，只要消息事務(wù)成功，那么服務(wù)A一定成功，消息也一定發(fā)出來(lái)了，這時(shí)候服務(wù)B會(huì)收到消息去執(zhí)行本地操作，如果本地操作失敗，消息會(huì)重投，直到服務(wù)B操作成功，這樣就變相地實(shí)現(xiàn)了A與B的分布式事務(wù)。

以上幾個(gè)步驟可能存在異常情況，現(xiàn)在對(duì)其進(jìn)行分析：

• 步驟一出錯(cuò)：則整個(gè)事務(wù)失敗，不會(huì)執(zhí)行服務(wù)A的本地操作。
• 步驟二出錯(cuò)：則整個(gè)事務(wù)失敗，不會(huì)執(zhí)行服務(wù)A的本地操作。
• 步驟三出錯(cuò)：需要做回滾預(yù)備消息，由服務(wù)A實(shí)現(xiàn)一個(gè)消息中間件的回調(diào)接口，消息中間件會(huì)不斷執(zhí)行回調(diào)接口，檢查服務(wù)A事務(wù)執(zhí)行是否執(zhí)行成功，如果失敗則回滾預(yù)備消息。
• 步驟四出錯(cuò)：這個(gè)時(shí)候服務(wù)A的本地事務(wù)是成功的，但是消息中間件不需要回滾，其實(shí)通過(guò)回調(diào)接口，消息中間件能夠檢查到服務(wù)A執(zhí)行成功了，這個(gè)時(shí)候其實(shí)不需要服務(wù)發(fā)提交消息了，消息中間件可以自己對(duì)消息進(jìn)行提交，從而完成整個(gè)消息事務(wù)。