2相コミット（2PC）と分散トランザクション

分散トランザクションが難しい理由

単一DB内なら、トランザクションは WAL（先行書き込みログ）と1つのコミットレコードで原子的に確定できます。ところが更新対象が複数のDBやサービスにまたがると、各ノードはそれぞれ独立にコミット/ロールバックを判断するため、「Aだけ成功してBは失敗」という中途半端な状態が起こりえます。これではACID の原子性（Atomicity）が崩れます。

この「全ノードを一斉に、全部成功か全部取消へそろえる」ための古典的合意プロトコルが 2相コミット（Two-Phase Commit, 2PC） です。1人の コーディネータ（調整役） が、複数の 参加者（各DBノード） の判断を取りまとめます。

prepare/commit の2フェーズ

名前のとおり、確定までを2段階に分けます。

フェーズ1: 準備（prepare / voting）

コーディネータが全参加者に prepare（投票要求）を送ります。各参加者は自分のローカル更新を実行し、コミット可能かを判断します。

• 可能なら、更新内容と「コミットすると約束した」事実を永続ログに書いてから YES（vote-commit）を返す。
• 制約違反やディスク不足などで無理なら NO（vote-abort）を返す。

ここが核心です。YES を返した参加者は、ロックを保持したまま自分ではもう結末を決められない「準備済み（prepared / in-doubt）」状態に入ります。あとはコーディネータの最終指示に従う義務を負います。

フェーズ2: 確定（commit / abort）

コーディネータは投票を集計します。

• 全員 YES なら、自分の決定をログに書いてから全員に commit を送る。
• 1人でも NO（または応答なし）なら、全員に abort を送る。

各参加者は指示どおりにローカルを確定し、ACK を返します。全 ACK が揃えばトランザクション完了です。

Coordinator                Participant A        Participant B
   |---- prepare ---------->|                    |
   |---- prepare ------------------------------->|
   |<--- YES ---------------|                    |
   |<--- YES -------------------------------------|
   | (全員YES → commit決定をログに記録)            |
   |---- commit ----------->|                    |
   |---- commit ------------------------------->|
   |<--- ACK ---------------|                    |
   |<--- ACK -------------------------------------|

ブロッキング問題

2PC の最大の弱点がブロッキングです。フェーズ1で YES を返した直後、フェーズ2の指示が届く前にコーディネータが落ちると何が起きるか。

準備済みの参加者は、自分の判断ではコミットもアボートもできません（勝手にコミットすれば、他参加者がアボートしていたとき不整合になる）。だからロックを握ったまま、コーディネータの復帰をひたすら待つしかありません。この間、対象データは他のトランザクションから触れず、最悪システム全体が固まります。

2PC は、参加者・ネットワークが一時的に落ちても最終的に正しく合意できる（安全性は保つ）プロトコルですが、いつ合意できるかを保証できません。これは分散システムの不可能性（非同期環境で耐障害かつ常に合意できる手段は存在しない）とも整合する性質です。

3PC との違い

ブロッキングを緩和しようと、フェーズを1つ増やしたのが 3相コミット（Three-Phase Commit, 3PC） です。prepare と commit の間に pre-commit を挟みます。

3PC の狙いは、「全員が YES だった」という事実を pre-commit で全参加者に行き渡らせてからコミットへ進む点にあります。これにより、コーディネータが落ちても、生存参加者は「pre-commit を受け取った＝全員 YES だったはず」と推論し、タイムアウト後に自分たちで commit へ前進できます。結果としてブロッキングは減ります。

実務での落としどころ

完全な原子性を諦めずに可用性も欲しい場合、純粋な 2PC/3PC ではなく次が選ばれがちです。

• Saga パターン: 大きな分散トランザクションを、各サービスのローカルトランザクションの連鎖に分解。失敗したら補償トランザクション（打ち消し処理）で巻き戻す。原子性は緩めるが、ロックを長く握らずブロッキングを避けられる。
• 合意アルゴリズム（Paxos / Raft）: コーディネータを単一障害点にせず、過半数の合意でコミット決定そのものを冗長化する。レプリケーションと組み合わせ、ノードが落ちても前進できる（レプリケーションとシャーディング参照）。

2PC は「複数ノードを原子的にそろえる」という難題への素直な解答で、XA トランザクションや PostgreSQL の PREPARE TRANSACTION など今も広く実装されています。ただしブロッキングという代償は消えません。だからこそ、本当に厳密な原子性が要る所だけ 2PC を使い、それ以外は Saga や合意ベースへ倒す――この使い分けが、分散データ設計の勘所です。