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

分布式事物常見解決方案:2PC兩段提交協(xié)議

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

TCC或者GTS(阿里)

消息中間件最終一致性

使用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 去支付，支付成功則處理購(gòu)物訂單為待發(fā)貨狀態(tài)，否則就需要將購(gòu)物訂單處理為失敗狀態(tài)。

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

1、第一階段：投票階段

第一階段主要分為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ù)庫(kù)本地事務(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ù)資源。

3、第二階段：提交/執(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ù)。

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

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

發(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)。

也就是說，除了引入超時(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ù)庫(kù)鎖 如果可以，就返回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者自身?yè)碛谐瑫r(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ù)不一致的問題。

總結(jié)

以上是生活随笔為你收集整理的3pc在mysql的实现_面试官：了解分布式事务？讲讲你理解的2PC和3PC原理的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。