二階段提交 (2PC)

引言：「全有或全無」的婚禮

想像一場婚禮。司儀問新郎新娘：「你願意嗎…？」

• 如果 兩人都 說「我願意」，婚姻就達成了 (Commit)。
• 如果 有一方 說「我不願意」（或暈倒了），婚禮對雙方都取消 (Abort)。

二階段提交 (2PC) 正是如此。在分散式系統中，當一個事務跨越多個資料庫時（例如：從 A 銀行扣錢，向 B 銀行加錢），我們需要確保她們達成共識。我們引入一個 協調者 (Coordinator) 來管理這個過程。

演算法要解決什麼問題？

• 輸入： 一個涉及多個節點的事務。
• 輸出： 原子的結果（提交或回滾）。
• 承諾： 一致性。如果一個節點失敗，沒有任何節點會執行提交。

演算法是如何工作的？

第一階段：準備階段 (投票)

1. 協調者 向所有參與節點發送「準備」請求。
2. 各節點在本地執行事務但不提交，並鎖定相關資源。
3. 各節點回覆：我準備好了 (Yes) 或 出錯了 (No)。

第二階段：提交階段 (執行)

1. 如果 所有人 都回覆了 Yes：協調者發送「提交」指令，各節點正式修改數據。
2. 如果 有任何人 回覆了 No（或超時）：協調者發送「回滾」指令，各節點撤銷之前的操作並釋放鎖。

典型業務場景

• ✅ 分散式資料庫： 關係型資料庫（如 Postgres 或 MySQL）在處理跨機器的 XA 事務時使用 2PC。

• ✅ 傳統金融/ERP 系統： 老牌銀行系統依賴 2PC 來保持帳目在不同系統間的一致。

• ❌ 高可用需求： 2PC 是 阻塞性 的。如果協調者在第二階段突然掛了，參與節點會一直拿著資源鎖動彈不得。

• ❌ 高性能需求： 因為她持有鎖的時間很長（兩次往返通訊），2PC 比較慢。現代大規模系統更傾向於使用 Saga 模式 或 TCC。

性能與複雜度總結

• 延遲： 較高（需要兩輪網路通訊）。
• 容錯性： 較弱。是一個同步阻塞協定。

小結：一句話記住它

「2PC 是『分散式婚禮』。她透過讓所有人在最終決定前先投票，確保了事務的原子性。她是正確性的標竿，但既慢又脆弱。」