Maxkit: 2-phase, 3-phase commit

在分散式系統，2-phase 與 3-phase commit 是用來處理多個節點的 transaction 的演算法，3PC 是解決 2PC 的缺點而設計的。

ACID

資料庫管理系統 DBMS 在寫入/更新資料時，會確保單一交易 transaction 的正確性，規定一個交易必須滿足 Atomicity, Consistency, Isolation, Durability 四個特性。

Atomicity 原子性

一個 transaction 裡面所有的資料操作，必須全部一起完成，或是全部一起失敗，在執行過程中如果發生任何問題，都必須 rollback 回到 transaction 一開始的狀態
Consistency 一致性

在 transaction 開始前，以及結束以後，資料庫要保持完整性，兩個狀態都是資料庫的某一個合法的狀態
Isolation 隔離原則

在多個 transaction 同時發生時，每一個 transaction 都必須各自獨立，即使對同一個資料進行異動，必須保證這幾個 transaction 之間不會互相影響，交查執行，而破壞了資料的一致性。

隔離有不同的等級：read uncommitted, read committed, repeatable read, serializable
Durability 持久性

當 transaction 結束後，對資料的修改必須是永久的，即使系統發生故障異常，也不會遺失資料

2-Phase Commit

在單一資料庫時，要維持 DBMS 的 ACID 原則比較簡單，但是如果商業邏輯牽涉了多個 DBMS，例如在購物時，必須同時異動倉儲管理及出貨管理兩個系統，這兩個系統的資料庫各自獨立。為了維持 ACID 原則，兩個 DBMS 必須同時異動，或是同時失敗，倉儲管理系統減少的商品數量 = 出貨管理增加的商品數量，2-Phase Commit 就是用來在分散式系統中達到 Data Stong Consistency 的方法。

角色

Coordinator

負責發起及維護 2PC 的流程，可能是 client 或 middleware，該角色不會異動到其他節點上
Participant

參與交易的 DBMS 或 Storage

假設

所有節點不會產生永久性破壞，異常後仍能恢復運作
交易的異動動作先放在預寫式日誌上，日誌會儲存在可靠的儲存設備上，即使節點被破壞，也不會遺失日誌資料
系統存在一個節點作為 coordinator，其他節點為 participants，不限制系統之間的通訊方法

方法

分為兩個 phase

Phase1 請求階段

coodinator 向 participants 發送 "Prepare" 詢問是否可參與交易
participants 執行詢問開始為止的所有 transactions，將 Undo, Redo 寫入日誌
participants 響應 "Prepare" 詢問，先複製一份預計被更新的資料，並回復兩種訊息
1. "Ready"：可成功參與交易
2. "Abort"：失敗

Phase2 執行階段

Ready

當所有 participants 都回覆 Ready 時

coordinator 向所有 participants 發送 "Commit"
participants 完成交易，釋放整個交易期間佔用的資源
participants 向 coordinator 發送 "Done"
coordinator 收到所有 participants 回送的 "Done" 完成交易

Abort

當有任一個 participant 回覆 "Abort" 時，或是 coordinator 詢問 Timeout 無法取得回覆時

coordinator 向所有 participants 發送 "Rollback"
participants 利用先前的 "Undo" 執行 rollback，釋放整個交易期間佔用的資源
participants 向 coordinator 發送 "Rollback Done"
cooridator 收到所有 participants 回送的 "Rollback Done"，取消交易

優缺點

優點：簡單，容易實作

缺點：

只有一個 coordinator，如果 coordinator 失效，則因為 participants 的同步呼叫操作，無法收到回覆而被 blocked，必須根據這種狀況另外實作 rollback 或是 abort 給 participants。

3-Phase Commit

為了解決 2PC 的問題，可使用 3PC

3PC 是一種 nonblocking 的協議。3PC 在 2PC 的第一階段與第二階段之間插入了一個準備階段，可解決在原先在 2PC 中，participant 在投票之後，由於 coordinator 發生崩潰或錯誤，而導致 participant 處於無法知曉是否提交或者中止的「不確定狀態」所產生的可能相當長的延時的問題。

3PC 將 Participants 改為 Cohorts