数千の並行トランザクションでデッドロックをどう防ぎますか？

Question

IT Interview Practice · Accepted Answer

**一貫したグローバルな順序でロックを取得し、トランザクションを短く保ち、安全な場合は分離レベルを下げ、それでもデッドロックが起きたら敗者をリトライします。** デッドロックはサイクルです。トランザクションAは行1を保持して行2を待ち、Bは行2を保持して行1を待つ — どちらも進めないので、DBが一方を殺します。

## 断ち切るべきサイクル

```text
   Tx A                              Tx B
   holds row 1  ──── waits ────▶ row 2 (held by B)
        ▲                              │
        │ waits                        │ holds
        └────────── row 1 ◀────────────┘
                (cycle = deadlock; DB aborts one victim)
```

## 戦略

- **一貫したロック順序。** すべてのトランザクションが常に同じ順序（例：主キーの昇順）で行をロックすれば、サイクルは不可能です。AとBは両方まず行1を掴むので、一方が単に待ちます。これが最大のレバーです。典型的なバグ：送金が `(from, to)` の順にアカウントをロックすると、逆方向の送金とデッドロックします。常に `min(id), max(id)` でロックします。
- **短いトランザクション。** ロックをできるだけ短く保ちます。検証、ネットワーク呼び出し、読み取りを `BEGIN` の**前**に行い、その後ロックし、書き込み、素早く `COMMIT` します。長いトランザクションはサイクルとロック待ちの窓を広げます。
- **安全な場合は分離レベルを下げる。** `SERIALIZABLE` はより多くの/レンジロックを取りデッドロックが増えます。`READ COMMITTED`（Postgresのデフォルト）はロックが少ないです。正しさを満たす最も弱い分離レベルを使います。
- **デッドロック時にリトライ。** デッドロックは一時的です。デッドロックエラー（Postgres `40P01`、MySQL `1213`）を捕捉し、小さなバックオフでトランザクション全体をリトライします。規模である程度の競合は避けられないので、リトライは順序付けの代替ではなくセーフティネットです。

## 面接での観点

面接官は、あなたがデッドロックは**捕捉するだけでなく設計で防ぐ**ものだと知っているかを確認します。「リトライ」だけを挙げるのは弱い回答です。優れた回答は**一貫したロック順序**と**短いトランザクション**を先頭に置き、残余のためにリトライを加えます。よくある罠：アプリがデッドロックを検知せねばならないと仮定すること。実際には**DBがサイクルを検知して犠牲者をアボート**してくれます。あなたの仕事は順序付けとリトライループです。

**トレードオフ：** アクセスパターンが動的だったりテーブルをまたいだりすると厳密な順序付けは難しいです。分離レベルを下げると、あなたが推論せねばならないアノマリー（non-repeatable read）のリスクがあります。リトライループは**冪等**で上限付きでなければ、ホットな競合がリトライの嵐になります。デッドロック防止は実のところ単一の銀の弾丸ではなく、ロック規律に加えた境界付きリトライです。

断ち切るべきサイクル

戦略

面接での観点

関連する質問