2PC必須注意的問(wèn)題

創(chuàng)新互聯(lián)專(zhuān)注于豐潤(rùn)網(wǎng)站建設(shè)服務(wù)及定制，我們擁有豐富的企業(yè)做網(wǎng)站經(jīng)驗(yàn)。 熱誠(chéng)為您提供豐潤(rùn)營(yíng)銷(xiāo)型網(wǎng)站建設(shè)，豐潤(rùn)網(wǎng)站制作、豐潤(rùn)網(wǎng)頁(yè)設(shè)計(jì)、豐潤(rùn)網(wǎng)站官網(wǎng)定制、微信小程序定制開(kāi)發(fā)服務(wù)，打造豐潤(rùn)網(wǎng)絡(luò)公司原創(chuàng)品牌,更為您提供豐潤(rùn)網(wǎng)站排名全網(wǎng)營(yíng)銷(xiāo)落地服務(wù)。

咱們上文介紹了分布式事務(wù)的常見(jiàn)方案、類(lèi)型劃分、2PC的起源和流程。但是不幸的是2PC還是存在幾個(gè)問(wèn)題：

1、全流程的同步阻塞：不管是第一階段還是第二階段，所有參與節(jié)點(diǎn)都是事務(wù)阻塞型。當(dāng)參與者占有公共資源時(shí)，其他第三方訪問(wèn)公共資源可能不得不處于阻塞狀態(tài)。

2、TM單點(diǎn)故障：由于全流程依賴(lài)TM的協(xié)調(diào)，一旦TM發(fā)生故障。參與者會(huì)一直阻塞下去。尤其在第二階段，TM發(fā)生故障，那么所有的參與者還都處于鎖定事務(wù)資源的狀態(tài)中，而無(wú)法繼續(xù)完成事務(wù)操作。所有參與者必須等待TM重新上線(TM重新選舉)后才能繼續(xù)工作。

3、TM腦裂引起數(shù)據(jù)不一致：在第二階段中，當(dāng)TM向參與者發(fā)送commit請(qǐng)求之后，發(fā)生了局部網(wǎng)絡(luò)異常或者在發(fā)送commit請(qǐng)求過(guò)程中TM發(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)象。

4、TM腦裂引起事務(wù)狀態(tài)不確定：TM再發(fā)出commit消息之后宕機(jī)，而接收到這條消息的參與者同時(shí)也宕機(jī)了。那么即使通過(guò)選舉協(xié)議產(chǎn)生了新的TM，這條事務(wù)的狀態(tài)也是不確定的，沒(méi)人知道事務(wù)是否被已經(jīng)提交。

3PC詳解來(lái)啦

一、3PC定義

2PC是CP的剛性事務(wù)，追求數(shù)據(jù)強(qiáng)一致性。但是通過(guò)我們上面分析可以得知TM腦裂可能造成數(shù)據(jù)不一致和事務(wù)狀態(tài)不確定問(wèn)題。無(wú)法達(dá)到CP的完美狀態(tài)。因此業(yè)界就出現(xiàn)了3PC，用來(lái)處理TM腦裂引起的數(shù)據(jù)不一致和事務(wù)狀態(tài)不確定問(wèn)題。

因?yàn)?PC是為徹底解決的2PC的數(shù)據(jù)不一致和事務(wù)狀態(tài)不確定問(wèn)題而出現(xiàn)。根據(jù)這一個(gè)前提，加上筆者對(duì)3PC的理解，總結(jié)出3PC的注釋事項(xiàng)：

1）3PC確保任何分支下的數(shù)據(jù)一致性
2）3PC確保任何分支最多3次握手得到最終結(jié)果(超時(shí)機(jī)制)
3）RM超時(shí)后的事務(wù)狀態(tài)必須從TM獲取。2PC只有TM的超時(shí)機(jī)制，3PC新增了參與者(RM)的超時(shí)機(jī)制，一方面輔助解決了2PC的事務(wù)/事務(wù)問(wèn)題，還能降低一定的同步阻塞問(wèn)題。因?yàn)門(mén)M、RM雙向超時(shí)機(jī)制，所以維基百科對(duì)3PC定義為“非阻塞”協(xié)議。

二、優(yōu)雅的3PC流程

3PC 分成3個(gè)階段：CanCommit(準(zhǔn)備階段)、PreCommit(對(duì)齊階段)、DoCommit(提交階段)；筆者根據(jù)資料對(duì)3階段進(jìn)行比較合適的翻譯，非官方翻譯。

準(zhǔn)備階段：跟2PC的表決階段很類(lèi)似，TM向參與者發(fā)送commit請(qǐng)求，參與者如果可以提交就返回Yes，否則返回No，詢問(wèn)超時(shí)默認(rèn)參與者為No。唯一差別在于SQL層面：準(zhǔn)備階段只做了SQL處理，并未記錄事務(wù)日志(Undo 和Redo)

對(duì)齊階段：TM 和 各個(gè)參與者對(duì)齊事務(wù)狀態(tài)，TM 通知各個(gè)參與者事務(wù)最終狀態(tài)，各個(gè)參與者如果一致未收到事務(wù)對(duì)齊通知，會(huì)在超時(shí)后從TM反查事務(wù)狀態(tài)實(shí)現(xiàn)事務(wù)狀態(tài)對(duì)齊。在SQL層面：事務(wù)狀態(tài)對(duì)齊后，記錄事務(wù)日志(Undo 和Redo)

提交階段：該階段進(jìn)行真正的事務(wù)提交。根據(jù)第二階段得到的事務(wù)狀態(tài)結(jié)果，各參與者根據(jù)TM的通知命令進(jìn)行提交/abort或者超時(shí)后自動(dòng)提交/abort。

下圖是筆者根據(jù)資料和個(gè)人理解整理出來(lái)的一個(gè)自認(rèn)為比較合理的3PC流程圖：

三、總結(jié)

或許3PC也不完美，網(wǎng)上有好多各版本的3PC的流程圖和解釋。有的甚至還存在明顯的問(wèn)題，為3PC的理解帶來(lái)了更大的苦難。身為架構(gòu)師，就需要去追尋本質(zhì)，了解3PC的前世今生，抓住3PC的本質(zhì)，就很容易理解3PC了。

對(duì)于數(shù)據(jù)一致性，Google Chubby的作者M(jìn)ike Burrows說(shuō)過(guò)：“there is only one consensus protocol, and that’s Paxos” – all other approaches are just broken versions of Paxos?！?/p>

譯文：世上只有一種一致性算法，那就是Paxos，所有其他一致性算法都是Paxos算法的不完整版。

更多免費(fèi)資料及視頻