在分布式系統(tǒng)中，每一個機(jī)器節(jié)點雖然都能夠明確地知道自己在進(jìn)行事務(wù)過程中的結(jié)果是成功或失敗，但卻無法直接獲取到其它分布式節(jié)點的操作結(jié)果。因此，當(dāng)一個事物操作需要跨越多個分布式節(jié)點的時候，為了保持事務(wù)處理的ACID特性，就需要引入一個成為“協(xié)調(diào)者”的組件來統(tǒng)一調(diào)度所有分布式節(jié)點的執(zhí)行邏輯，這些被調(diào)度的分布式節(jié)點則被稱為“參與者”。協(xié)調(diào)者負(fù)責(zé)調(diào)度參與者的行為，并最終決定這些參與者是否要把事務(wù)真正進(jìn)行提交。基于這個思想，衍生出了二階段提交和三階段提交兩種協(xié)議。

一.2PC

2PC，是Two-Phase Commit的縮寫，即二階段提交，是計算機(jī)網(wǎng)絡(luò)尤其是在數(shù)據(jù)庫領(lǐng)域內(nèi)，為了使基于分布式系統(tǒng)架構(gòu)下的所有節(jié)點在進(jìn)行事務(wù)處理過程中能夠保持原子性和一致性而設(shè)計的一種算法。通常，二階段提交協(xié)議也被認(rèn)為是一種一致性協(xié)議，用來保證分布式系統(tǒng)數(shù)據(jù)的一致性。目前，絕大部分的關(guān)系型數(shù)據(jù)庫都是采用二階段提交協(xié)議來完成分布式事務(wù)處理的，利用該協(xié)議能夠非常方便地完成所有分布式事務(wù)參與者的協(xié)調(diào)，統(tǒng)一決定事務(wù)的提交或回滾，從而能夠有效地保證分布式數(shù)據(jù)一致性。

顧名思義，二階段提交協(xié)議就是將事務(wù)的提交過程分成了兩個階段來進(jìn)行處理，執(zhí)行流程如下：

階段一：提交事務(wù)請求

1.事務(wù)詢問

協(xié)調(diào)者向所有的參與者發(fā)送事務(wù)內(nèi)容，詢問是否可以執(zhí)行事務(wù)提交操作，并開始等待各參與者的響應(yīng)。

2.執(zhí)行事務(wù)

各參與者節(jié)點執(zhí)行事務(wù)操作，并將Undo和Redo信息計入事務(wù)日志中。

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í)行。

總結(jié)：由于上面講述的內(nèi)容在形式上近似是協(xié)調(diào)者組織各參與者對一次事務(wù)操作的投票表態(tài)過程，因此二階段提交協(xié)議的階段一也被稱為“投票階段”，即各參與者投票表明是否要繼續(xù)執(zhí)行接下去的事務(wù)提交操作。

階段二：執(zhí)行事務(wù)提交

在階段二中，協(xié)調(diào)者會根據(jù)各參與者的反饋情況來決定最終是否可以進(jìn)行事務(wù)提交操作，正常情況下，包含以下兩種可能。

執(zhí)行事務(wù)提交

假如協(xié)調(diào)者從所有的參與者獲得的反饋都是Yes響應(yīng)，那么就會執(zhí)行事務(wù)提交

1.發(fā)送提交請求

協(xié)調(diào)者向所有參與者節(jié)點發(fā)出Commit請求

2.事務(wù)提交

參與者接收到Commit請求后，會正式執(zhí)行事務(wù)提交操作，并在完成提交之后釋放在整個事務(wù)執(zhí)行期間占用的事務(wù)資源

3.反饋事務(wù)提交結(jié)果

參與者在完成事務(wù)提交之后，向協(xié)調(diào)者發(fā)送ack消息

4.完成事務(wù)

協(xié)調(diào)者接收到所有參與者反饋的ack消息，完成事務(wù)

中斷事務(wù)

假如任何一個參與者向協(xié)調(diào)者反饋了No響應(yīng)，或者在等待超時之后，協(xié)調(diào)者尚無法接收到所有參與者的反饋響應(yīng)，就會中斷事務(wù)

1.發(fā)送回滾請求

協(xié)調(diào)者向所有參與者節(jié)點發(fā)出Rollback請求

2.事務(wù)回滾

參與者接收到Rollback請求后，會利用其在階段一中記錄的Undo信息來執(zhí)行事務(wù)回滾操作，并在完成回滾之后釋放整個事務(wù)執(zhí)行期間占用的資源

3.反饋事務(wù)回滾結(jié)果

參與者在完成事務(wù)回滾之后，向協(xié)調(diào)者發(fā)送ack消息

4.完成事務(wù)

協(xié)調(diào)者接收到所有參與者反饋的ack消息，完成事務(wù)中斷

---

以上就是二階段提交過程中，前后兩個階段分別進(jìn)行的處理邏輯。簡單地講，二階段提交將一個事務(wù)的處理過程分為了投票和執(zhí)行兩個階段，其核心是對每個事務(wù)都采用先嘗試后提交的處理方式。

“事務(wù)提交“示意圖如下：

?

”事務(wù)中斷“示意圖如下：

?

優(yōu)缺點

優(yōu)點：原理簡單，實現(xiàn)方便

缺點：同步阻塞，單點問題，數(shù)據(jù)不一致、太過保守

同步阻塞

在二階段提交的執(zhí)行過程中，所有參與該事務(wù)操作的邏輯都處于阻塞狀態(tài)，也就是說，在二階段提交的執(zhí)行過程中，所有參與該事務(wù)操作的邏輯都處于阻塞狀態(tài)，這回極大地限制分布式系統(tǒng)的性能。

單點問題

一旦協(xié)調(diào)者出現(xiàn)問題，那么整個二階段提交流程將無法運轉(zhuǎn)，更為嚴(yán)重的是，如果是在階段二中出現(xiàn)問題的話，那么其它參與者將會一直處于鎖定事務(wù)資源的狀態(tài)中，無法繼續(xù)完成事務(wù)操作。

數(shù)據(jù)不一致

在階段二，即執(zhí)行事務(wù)提交的時候，當(dāng)協(xié)調(diào)者向所有的參與者發(fā)送Commit請求之后，發(fā)生了局部網(wǎng)絡(luò)異常或者是協(xié)調(diào)者在尚未發(fā)送完Commit請求之前自身發(fā)生了奔潰，導(dǎo)致最終只有部分參與者收到了Commit請求。于是整個分布式系統(tǒng)便會出現(xiàn)數(shù)據(jù)不一致的現(xiàn)象。

太過保守

如果在協(xié)調(diào)者指示參與者進(jìn)行事務(wù)提交詢問的過程中，參與者出現(xiàn)故障而導(dǎo)致協(xié)調(diào)者無法獲取到所有參與者的響應(yīng)信息的話，這時協(xié)調(diào)者只能依靠其自身的超時機(jī)制來判斷是否需要中斷事務(wù)，這樣的策略顯得比較保守。換句話說，二階段提交協(xié)議沒有設(shè)計較為完善的容錯機(jī)制，任何一個節(jié)點的失敗都會導(dǎo)致整個事務(wù)的失敗。

二.3PC

3PC，是Three-Phase Commit的縮寫，即三階段提交，是2PC的改進(jìn)版，將其二階段提交協(xié)議的“提交事務(wù)請求”過程一分為二，形成了CanCommit、PreCommit和do Commit三個階段組成的事務(wù)處理協(xié)議。

階段一：CanCommit

1.事務(wù)詢問

協(xié)調(diào)者向所有的參與者發(fā)送一個包含事務(wù)內(nèi)容的canCommit請求，詢問是否可以執(zhí)行事務(wù)提交操作，并開始等待各參與者的響應(yīng)

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

參與者在接收到來自協(xié)調(diào)者的canCommit請求后，正常情況下，如果其自身認(rèn)為可以順利執(zhí)行事務(wù)，那么會反饋Yes響應(yīng)，并進(jìn)入預(yù)備狀態(tài)，否則反饋No響應(yīng)

階段二：PreCommit

在階段二中，協(xié)調(diào)者會根據(jù)各參與者的反饋情況來決定是否可以進(jìn)行事務(wù)的PreCommit操作，正常情況下，包含兩種可能。

執(zhí)行事務(wù)預(yù)提交

假如協(xié)調(diào)者從所有的參與者獲得的反饋都是Yes響應(yīng)，那么就會執(zhí)行事務(wù)預(yù)提交。

1.發(fā)送預(yù)提交請求

協(xié)調(diào)者向所有參與者節(jié)點發(fā)出preCommit的請求，并進(jìn)入Prepared階段

2.事務(wù)預(yù)提交

參與者接收到preCommit請求后，會執(zhí)行事務(wù)操作，并將Undo和Redo信息記錄到事務(wù)日志中

3.各參與者向協(xié)調(diào)者反饋事務(wù)執(zhí)行的響應(yīng)

如果參與者成功執(zhí)行了事務(wù)操作，那么就會反饋給協(xié)調(diào)者ack響應(yīng)，同時等待最終的指令：提交或中止

中斷事務(wù)

假如任何一個參與者向協(xié)調(diào)者反饋了No響應(yīng)，或者在等待超時之后，協(xié)調(diào)者尚無法接收到所有參與者的反饋響應(yīng)，那么就會中斷事務(wù)

1.發(fā)送中斷請求

協(xié)調(diào)者向所有參與者節(jié)點發(fā)出abort請求

2.中斷事務(wù)

無論是收到來自協(xié)調(diào)者的abort請求，或者是在等待協(xié)調(diào)者請求過程中出現(xiàn)超時，參與者都會中斷事務(wù)

階段三：doCommit

該階段將進(jìn)行真正的事務(wù)提交，會存在以下兩種可能的情況。

執(zhí)行提交

1.發(fā)送提交請求

進(jìn)入這一階段，假設(shè)協(xié)調(diào)者處于正常工作狀態(tài)，并且它接收到了來自所有參與者的ack響應(yīng)，那么它將從“預(yù)提交”狀態(tài)轉(zhuǎn)換到“提交”狀態(tài)，并向所有的參與者發(fā)送doCommit請求。

2.事務(wù)提交

參與者接收到doCommit請求后，會正式執(zhí)行事務(wù)提交操作，在完成提交后釋放整個事務(wù)執(zhí)行期間占用的事務(wù)資源。

3.反饋事務(wù)提交結(jié)果

參與者在完成事務(wù)提交之后，向協(xié)調(diào)者發(fā)送ack消息

4.完成事務(wù)

協(xié)調(diào)者接收到所有參與者反饋的ack消息后，完成事務(wù)

中斷事務(wù)

進(jìn)入這一階段，假設(shè)協(xié)調(diào)者處于正常工作狀態(tài)，并且有任意一個參與者向協(xié)調(diào)者反饋了No響應(yīng)，或者在等待超時之后，協(xié)調(diào)者尚無法接收到所有參與者的反饋響應(yīng)，那么就會中斷事務(wù)。

1.發(fā)送中斷請求

協(xié)調(diào)者向所有的參與者節(jié)點發(fā)送abort請求。

2.事務(wù)回滾

參與者接收到abort請求后，會利用其在階段二中記錄的Undo信息來執(zhí)行事務(wù)回滾操作，并在完成回滾之后釋放整個事務(wù)執(zhí)行期間占用的資源。

3.反饋事務(wù)回滾結(jié)果

參與者在完成事務(wù)回滾之后，向協(xié)調(diào)者發(fā)送ack消息。

4.中斷事務(wù)

協(xié)調(diào)者接收到所有參與者反饋的ack消息后，中斷事務(wù)

需要注意的是，一旦進(jìn)入到階段三，可能會存在以下兩種故障：

• 協(xié)調(diào)者出現(xiàn)問題

• 協(xié)調(diào)者和參與者之間的網(wǎng)絡(luò)出現(xiàn)故障

無論出現(xiàn)哪種情況，最終都會導(dǎo)致參與者無法接收到來自協(xié)調(diào)者的doCommit或者abort請求，針對這樣的異常情況，參與者都會在等待超時之后，繼續(xù)進(jìn)行事務(wù)提交。

優(yōu)缺點

優(yōu)點：降低了參與者的阻塞范圍，并且能夠在出現(xiàn)單點故障后繼續(xù)達(dá)成一致

缺點：在參與者接收到preCommit消息后，如果網(wǎng)絡(luò)出現(xiàn)分區(qū)，此時協(xié)調(diào)者所在的節(jié)點和參與者無法進(jìn)行正常的網(wǎng)絡(luò)通信，在這種情況下，該參與者依然會進(jìn)行事務(wù)的提交，這必然出現(xiàn)事務(wù)的不一致性

總結(jié)

以上是生活随笔為你收集整理的分布式之2PC与3PC提交协议的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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