佐賀パターンと分散トランザクション

1）なぜサガが必要なのか

古典的な2PC （2相ラッチ）はスケーラブルではなく、障害時に複雑になり、リソースをブロックします。佐賀は、全体的なビジネスプロセスを、それぞれ独立してコミットするローカルトランザクション（ステップ）のシーケンスに分解します。失敗した場合は、その後のステップはキャンセルされ、すでに完了しているものは逆操作によって補償されます。
結果：グローバルブロッキング、高い生存性、明確な回復プロトコルなしで最終的な一貫性を管理します。

2）基本モデル

2.1オーケストレーション

専用の佐賀コーディネーターが手順を管理します：コマンドの送信、応答/イベントの待機、補償の開始。
長所：集中制御、単純な観測性、明示的な期限。短所：オプションのコンポーネント。

2.2コレオグラフィー

コーディネーターはいません。サービスはお互いのイベントに応答します（"OrderPlaced→""PaymentCaptured'→"InventoryReserved……"）。
長所：弱い接続性。短所：追跡するのは難しい、明確なルールなしで「死のダンス」のリスク。

2.3 TCC （Try-Confirm/Cancel）

「凍結」リソースのオプション：

1.試してみてください-準備/予約、

2.確認-固定、

3.キャンセル-ロールバック。

保証はより高いですが、契約と予約のタイムアウトはより複雑です。

3）ステップと補償契約

各ステップ=ローカルトランザクション+補償（idempotent、繰り返しを許可）。
補償は完全に「世界を返す」ために必要ではありません-ドメイン同等性は十分です（例えば「、支払いを削除する」の代わりに「返金」）。
不変量を定義する：お金の-残高はマイナスになりません。注文の場合-「ハング」状態はありません。
期限/TTL準備金と期限切れの試みのための「ガベージコレクター」を入力してください。

4）一貫性と配信意味論

メッセージ配信：最低1回（デフォルト）→すべての操作はidempotentでなければなりません。

順序： 相関キーによって重要（例えば。'order_id'、 'player_id'）

正確に一度は佐賀の目標ではありません。私達はidempotentキー、outbox/inboxおよび正しいcommitingによって有効な均等性を達成します。

5）佐賀の状態とそのログ

保存するもの：

'saga_id'、 'correlation_id'、現在のステータス（実行/完了/補償/補償/失敗）、
ステップとその変数（支払い/予約ID）、
イベント/意思決定の履歴（ログ）、タイムスタンプ、締め切り、リトレイの数。

保管場所：

別売りの佐賀店（テーブル/ドキュメント）をコーディネーターにご用意しています。
振付のために-佐賀のローカル「エージェント」、共通のトピックでステータスイベントを公開します。

6）信頼できる出版パターン： outbox/inbox

Outbox：ステップは変更をコミットし、1つのトランザクションでevent/commandをoutboxテーブルに書き込みます。労働者はタイヤに出版します。
受信トレイ：消費者は処理された'message_id'→dedup+idempotencyのテーブルを維持します。
成功した副作用のコミットオフセット/ACK （Kafka/RabbitMQ）-以前ではありません。

7）佐賀工程の設計

7.1例（iGaming/eコマース購入）

1.PlaceOrder→ステータス'PENDING'。
2.AuthorizePayment （Try）→'payment_hold_id'。
3.ReserveInventory→'reservation_id'。
4.CapturePayment（確認）。
5.FinalizeOrder→'COMPLETED'。

補償：

（3） 'CancelPaymentHold'→が失敗した場合；
（4）（3）→'ReleaseInventory'の後に失敗しました。
（5） 'RefundPayment'と'ReleaseInventory'→が失敗した場合。

7.2締め切り/リトリート

指数遅延+ジッタを持つ最大Nリトレイ。
超過した後-「補償」に移動します。
各ステップのnext_attempt_atとdeadline_atを保存します。

8）オーケストレーター対プラットフォーム

オプション：

軽量ホームオーケストレーター（マイクロサービス+佐賀テーブル）
プラットフォーム：Temporal/Cadence、 Camunda、 Netflix Conductor、 Zeebe-タイマー、リトレイ、長寿命のワークフロー、可視性、Webコンソールを提供します。
振付には、イベントカタログと厳格なステータス/キーコンベンションを使用してください。

9）統合プロトコル

9.1非同期（Kafka/RabbitMQ）

コマンド：'支払い。承認してください。v1'、'インベントリ。予約してください。v1'。
イベント："支払い。承認されました。v1'、'インベントリ。予約しました。v1'、'支払い。捕獲された。v1'、'支払い。返金されます。v1'。

Part key='order_id'/'player_id'

9.2ステップ内の同期（HTTP/gRPC）

「短い」ステップで有効ですが、常にタイムアウト/リトレイ/idempotencyと非同期補正へのフォールバックがあります。

10） Idempotenceおよびキー

コマンドと補償リクエストでは、'idempotency_key'を渡します。
"idempotency_key"をまだ見ていない場合は実行してください"。
報酬もidempotentです：繰り返し'RefundPayment （id=X）'は安全です。

11）エラー処理

クラス：

トランジェント（ネットワーク/タイムアウト）→リトレイ/バックオフ。
ビジネス（資金不足、限度）→即時補償/代替パス。
回復不能→手動介入、手動補償。
ソリューションマトリックスを構築する：error type→action （retry/compensate/escalate）。

12）観察可能性およびSLOのsag

SLI/SLO：

サーガのエンドツーエンドのレイテンシ（p50/p95/p99）。
成功率。
補償率を補償する平均時間。
孤児のサガとGCへの時間。
トレース：'trace_id'/'saga_id'をステップ間のスパン・リンクとして指定します。エラー予算のバーンレート指標。

ログ：各サガのステータス変更=原因のある構造化されたレコード。

13）例（擬似コード）

13.1オーケストレーター（アイデア）

python def handle(OrderPlaced e):
saga = Saga. start(e. order_id)
saga. run(step=authorize_payment, compensate=cancel_payment)
saga. run(step=reserve_inventory, compensate=release_inventory)
saga. run(step=capture_payment, compensate=refund_payment)
saga. run(step=finalize_order, compensate=refund_and_release)
saga. complete()

def run(step, compensate):
try:
step () # local transaction + outbox except Transient:
schedule_retry()
except Business as err:
start_compensation(err)

13.2アウトボックス（テーブルアイデア）


outbox(id PK, aggregate_id, event_type, payload, created_at, sent_at NULL)
inbox(message_id PK, processed_at, status)
saga(order_id PK, state, step, next_attempt_at, deadline_at, context JSONB)
saga_log(id PK, order_id, time, event, details)

13.3振付（テーマのアイデア）

「オーダーズ」'→消費者： '支払い。authorize'、'inventory。［予約］

「支払い」認可された'+'インベントリ。予約'→'注文。try_finalize'

→'注文の失敗。'→initiated'支払いを補償します。キャンセル/払い戻し'、'在庫。release'。

14） 2PCおよびESとの比較

2PC：強い一貫性、しかし閉塞、ボトルネック、銅パイプ。
佐賀：最終的な一貫性、あなたは補償とテレメトリーの規律が必要です。
イベントソーシング：真実の源としてイベントを保存します。その上のサガは自然ですが、マイグレーション/スナップショットに複雑さを追加します。

15）安全性とコンプライアンス

トランスポートセキュリティ（TLS/mTLS）、トピック/キューごとのACL。
イベント-少なくともPII、機密フィールドの暗号化、トークン化。
サガと補償ログへのアクセスを監査します。
外部プロバイダとのSLA （payment/delivery）=期限とリトレイリミットパラメータ。

16）実装チェックリスト（0-45日）

0-10日

候補プロセスを選択します（マルチサービス、補償）。
モデル（オーケストレーション/振付/TCC）と相関キーを選択します。
ステップ/オフセット、不変量、期限について説明します。テーブル'saga'、 'outbox'、 'inbox'を上げます。

11-25日

outbox/inbox、 idempotency、およびバックオフリトレースを含める。
最初のサガを展開します。SLI/SLOダッシュボードとトレースを追加します。
補償（マニュアルを含む）とエスカレーションのランブックを書いてください。

26-45日

GCの「掛かる」サガを自動化して下さい、期限の周期的な再始動/連続。
ゲームの日を過ごす：ステップの失敗、期限超過、ブローカーの利用不能。
イベントコントラクト（バージョン、互換性）を標準化し「、sagaディレクトリ」を設定します。

17）アンチパターン

domain-correct reverseアクションの代わりに「Compensation=delete from database」。
outbox/inbox→イベント/ダブルエフェクトの損失なし。
jitter→self-DDoS依存関係のないレトライ。
「進行中の処理」なしで読むことの強い一貫性を期待する……。
すべての→制御モノリスのための1つの巨大なオーケストレーター。
可視性のないトータルコレオグラフィーとSLA→制御不能なダンス。
締め切りを無視する→永遠の準備/保持。

18）成熟度の指標

≥ 90％の重要なプロセスは、サガ/補償によってカバーされ、記述された不変量があります。
Outbox/inboxはすべてのTier-0/1の生産者/消費者のために統合されています。
SLO： p95エンドツーエンドの佐賀は正常です、成功率は安定しています、孤立<ターゲット。
透明なトレースとダッシュボード「ステップ」、バーンレートのアラート。
四半期ごとのゲームデーと手動のランブック補償チェック。

19）結論

Sagaは、明確なステップとリバースアクション、出版規律（outbox/inbox）、締め切りとリトレイ、観測性、補償プロセスなど、分散システムのための実用的な一貫性の契約です。モデル（オーケストレーション/振付/TSS）を選択し、不変量とキーを修正し、ハンドラをアイドルにします。マルチサービスのビジネスプロセスは、高価な2PCなしで予測可能で安定します。

佐賀パターンと分散トランザクション