前言
由於二階段提交存在著諸如同步阻塞、單點問題、腦裂等缺陷。所以，研究者們在二階段提交的基礎上做了改進，提出了三階段提交。
與兩階段提交不同的是，三階段提交有兩個改動點。
- 引入超時機制 - 同時在協調者和參與者中都引入超時機制。
- 在第一階段和第二階段中插入一個準備階段，保證了在最後提交階段之前各參與節點的狀態是一致的。
正文
1. 三階段提交的定義
三階段提交（Three-phase commit），也叫三階段提交協議（Three-phase commit protocol），是二階段提交（2PC）的改進版本。
所謂的三個階段分別是：詢問，然後再鎖資源，最後真正提交。
- 第一階段：CanCommit
- 第二階段：PreCommit
- 第三階段：Do Commit
2. 三階段提交的過程
2.1. 階段一：CanCommit
3PC的CanCommit階段其實和2PC的準備階段很像。協調者向參與者傳送commit請求，參與者如果可以提交就返回Yes響應，否則返回No響應。
a. 事務詢問
協調者向參與者傳送CanCommit請求。詢問是否可以執行事務提交操作。然後開始等待參與者的響應。
b. 響應反饋
參與者接到CanCommit請求之後，正常情況下，如果其自身認為可以順利執行事務，則返回Yes響應，並進入預備狀態；否則反饋No。
2.2. 階段二：PreCommit
協調者在得到所有參與者的響應之後，會根據結果執行2種操作：執行事務預提交，或者中斷事務。
2.2.1. 執行事務預提交
a. 傳送預提交請求
協調者向所有參與者節點發出 preCommit 的請求，並進入 prepared 狀態。
b. 事務預提交
參與者受到 preCommit 請求後，會執行事務操作，對應 2PC 準備階段中的 “執行事務”，也會 Undo 和 Redo 資訊記錄到事務日誌中。
c. 各參與者響應反饋
如果參與者成功執行了事務，就反饋 ACK 響應，同時等待指令：提交（commit） 或終止（abort）。
2.2.2. 中斷事務
a. 傳送中斷請求
協調者向所有參與者節點發出 abort 請求 。
b. 中斷事務
參與者如果收到 abort 請求或者超時了，都會中斷事務。
2.3. 階段三：Do Commit
該階段進行真正的事務提交，也可以分為以下兩種情況。
2.3.1. 執行提交
a. 傳送提交請求
協調者接收到各參與者傳送的ACK響應，那麼他將從預提交狀態進入到提交狀態。並向所有參與者傳送 doCommit 請求。
b. 事務提交
參與者接收到 doCommit 請求之後，執行正式的事務提交。並在完成事務提交之後釋放所有事務資源。
c. 響應反饋
事務提交完之後，向協調者傳送 ACK 響應。
d. 完成事務
協調者接收到所有參與者的 ACK 響應之後，完成事務。
2.3.2. 中斷事務
協調者沒有接收到參與者傳送的 ACK 響應（可能是接受者傳送的不是ACK響應，也可能響應超時），那麼就會執行中斷事務。
a. 傳送中斷請求
協調者向所有參與者傳送 abort 請求。
b. 事務回滾
參與者接收到 abort 請求之後，利用其在階段二記錄的 undo 資訊來執行事務的回滾操作，並在完成回滾之後釋放所有的事務資源。
c. 反饋結果
參與者完成事務回滾之後，向協調者傳送 ACK 訊息。
d. 中斷事務
協調者接收到參與者反饋的 ACK 訊息之後，完成事務的中斷。
3. 小結
3.1. 三階段提交的優點
相對於二階段提交，三階段提交主要解決的單點故障問題，並減少了阻塞的時間。
因為一旦參與者無法及時收到來自協調者的資訊之後，他會預設執行 commit。而不會一直持有事務資源並處於阻塞狀態。
3.2. 三階段提交的缺點
三階段提交也會導致資料一致性問題。由於網路原因，協調者傳送的 abort 響應沒有及時被參與者接收到，那麼參與者在等待超時之後執行了 commit 操作。
這樣就和其他接到 abort 命令並執行回滾的參與者之間存在資料不一致的情況。
相關連結
- 分散式理論(一) - CAP定理
- 分散式理論(二) - BASE理論
- 分散式理論(三) - 2PC協議
- 分散式理論(四) - 3PC協議
- 分散式理論(五) - 一致性演算法Paxos
- 分散式理論(六) - 一致性協議Raft
歡迎掃碼關注公眾號：零壹技術棧
本帳號將持續分享後端技術乾貨，包括虛擬機器基礎，多執行緒程式設計，高效能框架，非同步、快取和訊息中介軟體，分散式和微服務，架構學習和進階等學習資料和文章。