什麼是二階段提交事物？

2PC（Two Phase Commitment Protocol）

　　兩階段提交協議

　　實現分散式事務的關鍵就是兩階段提交協議。在此協議中，一個或多個資源管理器的活動均由一個稱為事務協調器的單獨軟體元件來控制。此協議中的五個步驟如下：

　　• 應用程式呼叫事務協調器中的提交方法。

　　• 事務協調器將聯絡事務中涉及的每個資源管理器，並通知它們準備提交事務（這是第一階段的開始）。

　　• 為 了以肯定的方式響應準備階段，資源管理器必須將自己置於以下狀態：確保能在被要求提交事務時提交事務，或在被要求回滾事務時回滾事務。大多數資源管理器會 將包含其計劃更改的日記檔案（或等效檔案）寫入持久儲存區中。如果資源管理器無法準備事務，它會以一個否定響應來回應事務協調器。

　　• 事務協調器收集來自資源管理器的所有響應。

　　• 在 第二階段，事務協調器將事務的結果通知給每個資源管理器。如果任一資源管理器做出否定響應，則事務協調器會將一個回滾命令傳送給事務中涉及的所有資源管理 器。如果資源管理器都做出肯定響應，則事務協調器會指示所有的資源管理器提交事務。一旦通知資源管理器提交，此後的事務就不能失敗了。通過以肯定的方式響 應第一階段，每個資源管理器均已確保，如果以後通知它提交事務，則事務不會失敗。

該協議將一個分散式的事務過程拆分成兩個階段：投票階段和事務提交階段。

為了讓整個資料庫叢集能夠正常的執行，該協議指定了一個“協調者”單 點，用於協調整個資料庫叢集的執行，為了簡化描述，我們將資料庫裡面的各個節點稱為“參與者”，

三階段提交協議中同樣包含“協調者”和“參與者”這兩個定 義。

第一階段：投票階段

該階段的主要目的在於打探資料庫叢集中的各個參與者是否能夠正常的執行事務，具體步驟如下：

1. 協調者向所有的參與者傳送事務執行請求，並等待參與者反饋事務執行結果。
2. 事務參與者收到請求之後，執行事務，但不提交，並記錄事務日誌。
3. 參與者將自己事務執行情況反饋給協調者，同時阻塞等待協調者的後續指令。

第二階段：事務提交階段

在第一階段協調者的詢盤之後，各個參與者會回覆自己事務的執行情況，這時候存在三種可能：

1. 所有的參與者回覆能夠正常執行事務
2. 一個或多個參與者回覆事務執行失敗
3. 協調者等待超時

對於第一種情況，協調者將向所有的參與者發出提交事務的通知，具體步驟如下：

1. 協調者向各個參與者傳送commit通知，請求提交事務。
2. 參與者收到事務提交通知之後，執行commit操作，然後釋放佔有的資源。
3. 參與者向協調者返回事務commit結果資訊。

對於第二、三種情況，協調者均認為參與者無法正常成功執行事務，為了整個叢集資料的一致性，所以要向各個參與者傳送事務回滾通知，具體步驟如下：

1. 協調者向各個參與者傳送事務rollback通知，請求回滾事務。
2. 參與者收到事務回滾通知之後，執行rollback操作，然後釋放佔有的資源。
3. 參與者向協調者返回事務rollback結果資訊。

兩階段提交協議解決的是分散式資料庫資料強一致性問題，其原理簡單，易於實現，但是缺點也是顯而易見的，主要缺點如下：

• 單點問題
  協調者在整個兩階段提交過程中扮演著舉足輕重的作用，一旦協調者所在伺服器宕機，那麼就會影響整個資料庫叢集的正常執行，比如在第二階段中，如果協調者因為故障不能正常傳送事務提交或回滾通知，那麼參與者們將一直處於阻塞狀態，整個資料庫叢集將無法提供服務。

• 同步阻塞
  兩階段提交執行過程中，所有的參與者都需要聽從協調者的統一排程，期間處於阻塞狀態而不能從事其他操作，這樣效率及其低下。

• 資料不一致性
  兩階段提交協議雖然為分散式資料強一致性所設計，但仍然存在資料不一致性的可能，比如在第二階段中，假設協調者發出了 事務commit的通知，但是因為網路問題該通知僅被一部分參與者所收到並執行了commit操作，其餘的參與者則因為沒有收到通知一直處於阻塞狀態，這 時候就產生了資料的不一致性。