兩階段提交(2PC) 是 Oracle Tuxedo 系統(tǒng)提出的 XA 分布式事務(wù)協(xié)議的其中一種實(shí)現(xiàn)方式。

XA協(xié)議中有兩個(gè)重要角色：事務(wù)協(xié)調(diào)者和事務(wù)參與者

既然叫兩階段提交，肯定是分為兩個(gè)階段。

Java 生態(tài)下可以使用atomikos來(lái)快速實(shí)現(xiàn)兩階段提交的分布式事務(wù)。

第一階段

順利的情況下

事務(wù)協(xié)調(diào)者的節(jié)點(diǎn)會(huì)首先向所有的參與者節(jié)點(diǎn)發(fā)送 Prepare(預(yù)備) 請(qǐng)求。

在接到 Prepare(預(yù)備) 請(qǐng)求之后，每一個(gè)參與者節(jié)點(diǎn)會(huì)各自執(zhí)行與事務(wù)有關(guān)的數(shù)據(jù)更新，寫(xiě)入U(xiǎn)ndo Log和Redo Log。

參與者執(zhí)行成功，暫時(shí)不提交事務(wù)，向事務(wù)協(xié)調(diào)節(jié)點(diǎn)返回 done(完成) 消息。

進(jìn)入第二階段

出錯(cuò)時(shí)

在XA的第一階段，如果某個(gè)事務(wù)參與者反饋失敗消息，說(shuō)明該節(jié)點(diǎn)的本地事務(wù)執(zhí)行不成功，必須回滾。

事務(wù)協(xié)調(diào)者的節(jié)點(diǎn)會(huì)首先向所有的參與者節(jié)點(diǎn)發(fā)送 Prepare(預(yù)備) 請(qǐng)求。

在接到 Prepare(預(yù)備) 請(qǐng)求之后，每一個(gè)參與者節(jié)點(diǎn)會(huì)各自執(zhí)行與事務(wù)有關(guān)的數(shù)據(jù)更新，寫(xiě)入U(xiǎn)ndo Log和Redo Log。

參與者執(zhí)行失敗，返回失敗消息。

協(xié)調(diào)者中斷事務(wù)

中斷事物

任何一個(gè)參與者向協(xié)調(diào)者反饋了 No 響應(yīng)，或者在等待超時(shí)之后，協(xié)調(diào)者尚無(wú)法接收到所有參與者的反饋?lái)憫?yīng)，那么就會(huì)中斷事物。

發(fā)送回滾請(qǐng)求。協(xié)調(diào)者向所有參與者節(jié)點(diǎn)發(fā)出 Rollback 請(qǐng)求。

事物回滾。參與者收到Rollback請(qǐng)求之后，會(huì)利用其在階段一種記錄的 Undo 信息來(lái)執(zhí)行事務(wù)回滾操作，并在完成回滾之后釋放在整個(gè)事物執(zhí)行期間占用的資源。

反饋事物回滾結(jié)果。參與者在完成事物回滾之后，向協(xié)調(diào)者發(fā)送 Ack 消息。

中斷事務(wù)

第二階段

在XA分布式事務(wù)的第二階段，如果事務(wù)協(xié)調(diào)節(jié)點(diǎn)在之前所收到都是正向返回，那么它將會(huì)向所有事務(wù)參與者發(fā)出Commit請(qǐng)求。

接到Commit請(qǐng)求之后，事務(wù)參與者節(jié)點(diǎn)會(huì)各自進(jìn)行本地的事務(wù)提交，并釋放鎖資源。當(dāng)本地事務(wù)完成提交后，將會(huì)向事務(wù)協(xié)調(diào)者返回“完成”消息。

當(dāng)事務(wù)協(xié)調(diào)者接收到所有事務(wù)參與者的“完成”反饋，整個(gè)分布式事務(wù)完成。

缺點(diǎn)

兩階段提交涉及多次節(jié)點(diǎn)間的網(wǎng)絡(luò)通信，通信時(shí)間長(zhǎng)！且在整個(gè)過(guò)程中，所有節(jié)點(diǎn)都處于阻塞狀態(tài)，所有節(jié)點(diǎn)所持有的資源(例如數(shù)據(jù)庫(kù)數(shù)據(jù)，本地文件等)都處于鎖定狀態(tài)

單點(diǎn)故障。由于協(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ò)異?；蛘咴诎l(fā)送commit請(qǐng)求過(guò)程中協(xié)調(diào)者發(fā)生了故障，這回導(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)象。

總結(jié)

以上是生活随笔為你收集整理的oracle二阶段事物,分布式事务 两阶段提交 (2PC)的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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