---
title: 分散トランザクション
url: https://doc.liz6.com/ja/distributed-systems/03-replication-and-consistency/03-distributed-transactions
locale: ja
area: distributed-systems
tags:
- 2PC
- XA
- Saga
- TCC
- compensating action
- idempotency
- outbox pattern
- distributed transaction
- distributed-systems
- replication-and-consistency
date: 2026-06-30
modified: 2026-07-16
description: 複数のサービスにまたがる1回の書き込み操作——グローバルなACIDは存在しない。2PCは強い整合性を追求するが、コーディネーターが障害発生すると参加者がすべてブロックされる。SagaやTCCは補償トランザクションで可用性と引き換えに、アプリケーション層でロールバックロジックを自前で実装する必要がある。outbox patternと冪等性により、実装上の「少なくとも1回」の配信が保証される。
---
# 分散トランザクション
> 複数のサービスにまたがる1回の書き込み操作——グローバルなACIDは存在しない。2PCは強い整合性を追求するが、コーディネーターが障害発生すると参加者がすべてブロックされる。SagaやTCCは補償トランザクションで可用性と引き換えに、アプリケーション層でロールバックロジックを自前で実装する必要がある。outbox patternと冪等性により、実装上の「少なくとも1回」の配信が保証される。
単一ノードのデータベースではトランザクションはACID準拠であり、BEGIN/COMMIT/ROLLBACKで制御できる。しかし分散システムでは複数のサービスが関与するため、グローバルなACIDトランザクションは存在しない。
## 2PC (Two-Phase Commit)
最も基本的な分散トランザクションプロトコル——ブロッキング型であり、コーディネーターの障害に対する耐性を持たない。
問題点: coordinatorがPREPARE後、COMMIT前にクラッシュした場合 → participantは不確実な状態(uncertain state)に陥る——他のparticipantがYESかどうか分からないため単独でコミットできず、他がすでにコミットしている可能性もあるため単独でアボートもできない。**参加者がブロック**され、coordinatorの回復を待つ——これが「ブロッキングプロトコル」である。
実務では: XAトランザクション（2PCの実装）はデータベースのシャーディング間トランザクションで使われるが、coordinatorのクラッシュへの対応には管理者によるヒューリスティックなコミット/アボートが必要になる。
## Saga
長時間のトランザクションを複数のローカルトランザクションステップに分割し、各ステップには独自の補償操作(compensating action)を持たせる。あるステップで失敗した場合、完了したステップを逆順で補償実行する。
Sagaには分離性がない（他のトランザクションが中間状態を見ることができる）が、ブロックしない——いつでもシステムは進行中(progressing)である。
### オーケストレーションモード
- **Choreography**: 各サービスが前のステップのイベントを消費し、自身の完了/失敗イベントを公開する——中央のオーケストレーターは存在しない
- **Orchestration**: 中央のSagaコーディネーターが各サービスに「ステップを実行」または「補償を実行」を指示する——ロジックが集中しており、管理が容易
## TCC (Try-Confirm-Cancel)
Sagaのバリエーションで、より「厳格な」リソース予約に適している。
```
Try: リソースを予約 (在庫確認、残高凍結) — リソースは**消費されていない**、単に「使用待ち」マーク
Confirm: リソースを実際に消費 (在庫減算、入金処理)
Cancel: 予約を解放 (在庫解放、残高解除)
```
Sagaとの違い: Sagaのステップはデータを直接変更する（book_flightは実際にチケットを予約する）、補償はundoである。TCCのTryは予約のみを行い、Confirmが実際に変更を行う——**いつでもCancelでき、後でundoを実行する必要がない**。
## 冪等性
分散システムにおいて最も重要な非機能的要件: `f(x) = f(f(x))`——再試行操作が結果に影響を与えない。
```
実装方法:
1. unique idempotency key: クライアントがUUIDを生成し、サーバーが保存 ((key) → (処理済み/未処理))
→ 重複するkey → キャッシュされた結果を返す、再実行しない
2. database constraints: INSERT INTO orders VALUES (order_id=123, ...)
→ 再試行 → UNIQUE制約違反 → 無視または既存レコードを読み取る
3. token-based: サーバーがクライアントにトークンを発行し、クライアントがリクエストにトークンを付与
→ 重複するtoken → 拒否
冪等でない例:
UPDATE users SET balance = balance + 100 -- 再試行 = 2回加算される!
修正: UPDATE users SET balance = ? WHERE version = ? (楽観的ロック)
```
## Outbox Pattern
トランザクションとしてデータベースに書き込み + メッセージキューにメッセージを送信——両者を原子性で保証するには？DBに書き込んでからメッセージを送信するのは不可（DB書き込みは成功したがメッセージ送信が失敗 → 不整合）。
```
[ローカルトランザクション]:
INSERT INTO orders (...);
INSERT INTO outbox (event_type, payload, created_at) VALUES ('order_created', '...', NOW());
COMMIT; ← 両方が同じローカルトランザクション内にある!
[Outbox Poller]:
SELECT * FROM outbox ORDER BY id → Kafka/MQに送信 → 成功 → outboxから削除
```
保証: orderの書き込み + eventの生成は原子性（同じトランザクション内）。Outbox pollerがat-least-once配信を行う。
## 参考
- **論文**: "Sagas" (Garcia-Molina & Salem, 1987)
- **マイクロサービストランザクション**: microservices.io/patterns/data/saga.html
- **冪等性**: stripe.com/docs/idempotency (本番環境レベルの実装)
*Keywords: 2PC, XA, Saga, TCC, compensating action, idempotency, outbox pattern, distributed transaction*