分佈式理論(四) - 3PC協議

前言

因爲二階段提交存在着諸如同步阻塞、單點問題、腦裂等缺陷。因此，研究者們在二階段提交的基礎上作了改進，提出了三階段提交。

與兩階段提交不一樣的是，三階段提交有兩個改動點。

1. 引入超時機制 - 同時在協調者和參與者中都引入超時機制。
2. 在第一階段和第二階段中插入一個準備階段，保證了在最後提交階段以前各參與節點的狀態是一致的。

正文

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 命令並執行回滾的參與者之間存在數據不一致的狀況。

相關連接

1. 分佈式理論(一) - CAP定理
2. 分佈式理論(二) - BASE理論
3. 分佈式理論(三) - 2PC協議
4. 分佈式理論(四) - 3PC協議
5. 分佈式理論(五) - 一致性算法Paxos
6. 分佈式理論(六) - 一致性協議Raft

---

歡迎掃碼關注公衆號：零壹技術棧

本賬號將持續分享後端技術乾貨，包括虛擬機基礎，多線程編程，高性能框架，異步、緩存和消息中間件，分佈式和微服務，架構學習和進階等學習資料和文章。