Как предотвратить deadlock при тысячах конкурентных транзакций?

Question

IT Interview Practice · Accepted Answer

**Захватывайте блокировки в едином глобальном порядке, держите транзакции короткими, снижайте isolation там, где это безопасно, и повторяйте проигравшего, когда deadlock всё же случается.** Deadlock — это цикл: транзакция A держит строку 1 и ждёт строку 2, а B держит строку 2 и ждёт строку 1 — ни одна не может продолжить, поэтому БД убивает одну.

## Цикл, который нужно разорвать

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

## Стратегии

- **Единый порядок блокировок.** Если каждая транзакция всегда блокирует строки в одном порядке (например, по возрастанию primary key), цикл невозможен — A и B обе хватают строку 1 первой, так что одна просто ждёт. Это самый большой рычаг. Классический баг: денежный перевод, блокирующий счета в порядке `(from, to)`, входит в deadlock с обратным переводом; всегда блокируйте по `min(id), max(id)`.
- **Короткие транзакции.** Держите блокировки как можно меньше времени — делайте валидацию, сетевые вызовы и чтения **до** `BEGIN`, затем быстро блокируйте, пишите и `COMMIT`. Длинные транзакции расширяют окно для циклов и ожиданий блокировок.
- **Снижайте isolation, где безопасно.** `SERIALIZABLE` берёт больше/range-блокировок и чаще входит в deadlock; `READ COMMITTED` (дефолт Postgres) блокирует меньше. Используйте самый слабый isolation, всё ещё отвечающий корректности.
- **Повтор при deadlock.** Deadlock-и транзиентны. Ловите ошибку deadlock (Postgres `40P01`, MySQL `1213`) и повторяйте всю транзакцию с малым backoff. Часть конкуренции на масштабе неизбежна, поэтому повтор — это подстраховка, а не замена упорядочивания.

## Взгляд с точки зрения интервью

Интервьюер проверяет, знаете ли вы, что deadlock-и **предотвращаются дизайном, а не просто ловятся**. Назвать один «повтор» — слабый ответ; отличный ответ ведёт с **единого порядка блокировок** и **коротких транзакций**, затем добавляет повтор для остаточного. Частая ловушка: считать, что приложение должно обнаруживать deadlock-и; на практике **БД обнаруживает цикл и прерывает жертву** за вас — ваша задача — упорядочивание плюс retry-цикл.

**Компромиссы:** строгое упорядочивание бывает трудным, когда паттерны доступа динамичны или охватывают несколько таблиц; более низкий isolation рискует аномалиями (non-repeatable reads), о которых нужно рассуждать. Retry-циклы должны быть **идемпотентными** и ограниченными, иначе горячий конфликт превращается в retry-шторм. Предотвращение deadlock — это на самом деле дисциплина блокировок плюс ограниченный повтор, а не единая серебряная пуля.

Цикл, который нужно разорвать

Стратегии

Взгляд с точки зрения интервью

Похожие вопросы