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

一.2PC

2PC，是Two-Phase Commit的縮寫，即二階段提交，是計算機網絡尤其是在數據庫領域內，為了使基于分布式系統架構下的所有節點在進行事務處理過程中能夠保持原子性和一致性而設計的一種算法。通常，二階段提交協議也被認為是一種一致性協議，用來保證分布式系統數據的一致性。目前，絕大部分的關系型數據庫都是采用二階段提交協議來完成分布式事務處理的，利用該協議能夠非常方便地完成所有分布式事務參與者的協調，統一決定事務的提交或回滾，從而能夠有效地保證分布式數據一致性。

顧名思義，二階段提交協議就是將事務的提交過程分成了兩個階段來進行處理，執行流程如下：

階段一：提交事務請求

1.事務詢問

協調者向所有的參與者發送事務內容，詢問是否可以執行事務提交操作，并開始等待各參與者的響應。

2.執行事務

各參與者節點執行事務操作，并將Undo和Redo信息計入事務日志中。

3.各參與者向協調者反饋事務詢問的響應

如果參與者成功執行了事務操作，那么就反饋給協調者Yes響應，表示事務可以執行；如果參與者沒有成功執行事務，那么就反饋給協調者No響應，表示事務不可以執行。

總結：由于上面講述的內容在形式上近似是協調者組織各參與者對一次事務操作的投票表態過程，因此二階段提交協議的階段一也被稱為“投票階段”，即各參與者投票表明是否要繼續執行接下去的事務提交操作。

階段二：執行事務提交

在階段二中，協調者會根據各參與者的反饋情況來決定最終是否可以進行事務提交操作，正常情況下，包含以下兩種可能。

執行事務提交

假如協調者從所有的參與者獲得的反饋都是Yes響應，那么就會執行事務提交

1.發送提交請求

協調者向所有參與者節點發出Commit請求

2.事務提交

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

3.反饋事務提交結果

參與者在完成事務提交之后，向協調者發送ack消息

4.完成事務

協調者接收到所有參與者反饋的ack消息，完成事務

中斷事務

假如任何一個參與者向協調者反饋了No響應，或者在等待超時之后，協調者尚無法接收到所有參與者的反饋響應，就會中斷事務

1.發送回滾請求

協調者向所有參與者節點發出Rollback請求

2.事務回滾

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

3.反饋事務回滾結果

參與者在完成事務回滾之后，向協調者發送ack消息

4.完成事務

協調者接收到所有參與者反饋的ack消息，完成事務中斷

---

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

“事務提交“示意圖如下：

?

”事務中斷“示意圖如下：

?

優缺點

優點：原理簡單，實現方便

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

同步阻塞

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

單點問題

一旦協調者出現問題，那么整個二階段提交流程將無法運轉，更為嚴重的是，如果是在階段二中出現問題的話，那么其它參與者將會一直處于鎖定事務資源的狀態中，無法繼續完成事務操作。

數據不一致

在階段二，即執行事務提交的時候，當協調者向所有的參與者發送Commit請求之后，發生了局部網絡異常或者是協調者在尚未發送完Commit請求之前自身發生了奔潰，導致最終只有部分參與者收到了Commit請求。于是整個分布式系統便會出現數據不一致的現象。

太過保守

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

二.3PC

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

階段一：CanCommit

1.事務詢問

協調者向所有的參與者發送一個包含事務內容的canCommit請求，詢問是否可以執行事務提交操作，并開始等待各參與者的響應

2.各參與者向協調者反饋事務詢問的響應

參與者在接收到來自協調者的canCommit請求后，正常情況下，如果其自身認為可以順利執行事務，那么會反饋Yes響應，并進入預備狀態，否則反饋No響應

階段二：PreCommit

在階段二中，協調者會根據各參與者的反饋情況來決定是否可以進行事務的PreCommit操作，正常情況下，包含兩種可能。

執行事務預提交

假如協調者從所有的參與者獲得的反饋都是Yes響應，那么就會執行事務預提交。

1.發送預提交請求

協調者向所有參與者節點發出preCommit的請求，并進入Prepared階段

2.事務預提交

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

3.各參與者向協調者反饋事務執行的響應

如果參與者成功執行了事務操作，那么就會反饋給協調者ack響應，同時等待最終的指令：提交或中止

中斷事務

假如任何一個參與者向協調者反饋了No響應，或者在等待超時之后，協調者尚無法接收到所有參與者的反饋響應，那么就會中斷事務

1.發送中斷請求

協調者向所有參與者節點發出abort請求

2.中斷事務

無論是收到來自協調者的abort請求，或者是在等待協調者請求過程中出現超時，參與者都會中斷事務

階段三：doCommit

該階段將進行真正的事務提交，會存在以下兩種可能的情況。

執行提交

1.發送提交請求

進入這一階段，假設協調者處于正常工作狀態，并且它接收到了來自所有參與者的ack響應，那么它將從“預提交”狀態轉換到“提交”狀態，并向所有的參與者發送doCommit請求。

2.事務提交

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

3.反饋事務提交結果

參與者在完成事務提交之后，向協調者發送ack消息

4.完成事務

協調者接收到所有參與者反饋的ack消息后，完成事務

中斷事務

進入這一階段，假設協調者處于正常工作狀態，并且有任意一個參與者向協調者反饋了No響應，或者在等待超時之后，協調者尚無法接收到所有參與者的反饋響應，那么就會中斷事務。

1.發送中斷請求

協調者向所有的參與者節點發送abort請求。

2.事務回滾

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

3.反饋事務回滾結果

參與者在完成事務回滾之后，向協調者發送ack消息。

4.中斷事務

協調者接收到所有參與者反饋的ack消息后，中斷事務

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

• 協調者出現問題

• 協調者和參與者之間的網絡出現故障

無論出現哪種情況，最終都會導致參與者無法接收到來自協調者的doCommit或者abort請求，針對這樣的異常情況，參與者都會在等待超時之后，繼續進行事務提交。

優缺點

優點：降低了參與者的阻塞范圍，并且能夠在出現單點故障后繼續達成一致

缺點：在參與者接收到preCommit消息后，如果網絡出現分區，此時協調者所在的節點和參與者無法進行正常的網絡通信，在這種情況下，該參與者依然會進行事務的提交，這必然出現事務的不一致性

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。