一、協議概述

兩階段提交協議（2-phase-commit protocol，2PC）可以保證數據的強一致性，許多分布式關系型數據管理系統采用此協議來完成分布式事務。它是協調所有分布式原子事務參與者，并決定提交或回滾的分布式算法。也是解決一致性問題的一致性算法。為了能夠使參與者從故障在恢復，采用日志記錄協議的狀態，雖然使用日志降低了性能但是節點能從故障中恢復。

在2PC中，系統一般含兩類節點：

① 協調者 coordinator，通常一個系統中只有一個

② 參與者 workers，一般含多個，在數據存儲系統中可以理解為數據副本的個數

協議中假設：

① 每個節點都記錄寫前日志并持久性存儲，即使節點故障日志也不會丟失

② 節點不會發生永久性故障且任意兩個節點間可以相互通信

當事務最后一步完成，協調者執行協議，參與者根據本地事務，能夠成功完成回復同意提交事務或者回滾事務。

?

二、執行過程

兩階段提交由兩個階段組成：

1. 請求階段（commit-request phase）

在此階段，協調者通知事務參與者準備提交或回滾事務，然后進入表決過程：在表決過程中，參與者將告知協調者自己的決策：同意（事務參與者本地作業執行成功）或回滾（本地作業執行故障）

2. 提交階段（commit phase）

在該階段，協調者基于第一個階段的結果進行決策：提交或取消。當且僅當所有參與者回復同意，才通知所有事務參與者提交事務，否則協調者將通知事務參與者回滾事務。參與者在接收到協調者發來的消息后執行相應的操作。

?

三、協議的特點

兩階段提交系統通過阻塞完成協議，在節點等待消息的時候處于阻塞狀態，節點中其他進程需等待阻塞進程釋放資源才能使用。如果協調器發生了故障，那么事務參與者則會一直等待。以下情況可能會導致節點發生永久阻塞：

（1） 參與者發送同意提交消息給協調者，進程將阻塞直到協調者發消息。若協調者永久故障，參與者將一直等待。此問題可通過備份協調器解決。

（2）若協調器發送“請求提交”給所有參與者，它將被阻塞直到所有參與者回復。若某參與者永久故障，那么協調器也不會一直阻塞。在某一時間內還未收到某參與者消息，它將通知其他參與者回滾事務。

2PL沒有容錯機制，一個節點故障整個事務都回滾，代價較大。

?

四、工作過程

通過一個例子說明兩階段提交協議的工作過程：

A是保險公司銷售小組組長，負責召開會議，B，C，D是苦逼的保險推銷員。公司規定由組長召開小組會議，必須全員到場。A在星期六晚上發送下周一召開會議的通知給B，C，D。如果所有人周一都有時間來開會，那么會議將如期開展；若有任何一個有事不能在現場，則會議取消另定時間。用2PC算法解決過程：

A是協調者，B，C，D是該會議的參與者：

（1）請求階段：

① A發送郵件給B，C，D，通知周一舉行會議，詢問是否都能到場。A此時等待B，C，D的回復郵件

② B，C，D分別查看自己的日程按排。B，C發現周一沒有約見客戶的日程安排，身為苦逼的員工當然得去開會！于是發郵件告訴A，會按時到場。由于某種原因，D白天沒有查看郵件。那么此時A，B，C都需要等待。到晚上D發現了A的郵件，查看自己的日程安排，發現周一正好要去見客戶，那么D就回復A：我要出外勤，無法參會，會議能不能改天？

（2）提交階段（commit phase）

① A已經收到所有參與者的郵件，發現D因為公事無法參加周一的會議，于是 A發郵件通知 B，C，D。下周一的會議取消。

② 此時 B，C心里樂開了花，不用開會。至此事務結束。

?

通過上面的例子可以發現，2PC存在一定問題。如果D一直不回復郵件，那么A,B,C將一直處于等待狀態。而且B,C所持有的資源，即周一不可以安排其他活動（見客戶，上門推銷保險...），一直不能釋放。其他等待該資源釋放的活動也不得不處于等待狀態。

?

部分引用自：https://www.cnblogs.com/sunddenly/articles/4072882.html

總結

以上是生活随笔為你收集整理的2PC协议（2-phase-commit protocol）的全部內容，希望文章能夠幫你解決所遇到的問題。

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