수천 개의 동시 트랜잭션에서 deadlock을 어떻게 방지하시겠습니까?

Question

IT Interview Practice · Accepted Answer

**lock을 일관된 전역 순서로 획득하고, 트랜잭션을 짧게 유지하며, 안전한 곳에서는 isolation을 낮추고, 그래도 deadlock이 발생하면 패자(loser)를 재시도하십시오.** deadlock은 순환(cycle)입니다: 트랜잭션 A가 row 1을 잡고 row 2를 기다리는 동안 B는 row 2를 잡고 row 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)
```

## 전략

- **일관된 lock 순서.** 모든 트랜잭션이 항상 같은 순서로 row를 lock하면(예: primary key 오름차순), 순환은 불가능합니다 — A와 B가 모두 row 1을 먼저 잡으므로 하나가 그냥 기다립니다. 이것이 단 하나의 가장 큰 레버입니다. 전형적인 버그: `(from, to)` 순서로 계정을 lock하는 송금이 역방향 송금과 deadlock합니다. 항상 `min(id), max(id)`로 lock하십시오.
- **짧은 트랜잭션.** lock을 가능한 한 짧게 잡으십시오 — 검증, 네트워크 호출, read를 `BEGIN` **전에** 하고, 그다음 빠르게 lock, write, `COMMIT`하십시오. 긴 트랜잭션은 순환과 lock 대기의 창을 넓힙니다.
- **안전한 곳에서 isolation 낮추기.** `SERIALIZABLE`은 더 많은/range lock을 잡아 deadlock이 더 잦고, `READ COMMITTED`(Postgres 기본값)는 lock이 더 적습니다. 정확성을 만족하는 가장 약한 isolation을 쓰십시오.
- **Deadlock 시 재시도.** deadlock은 일시적입니다. deadlock 오류(Postgres `40P01`, MySQL `1213`)를 잡아 작은 backoff로 트랜잭션 전체를 재시도하십시오. 규모에서는 일부 경합이 불가피하므로, 재시도는 순서 지정의 대체물이 아니라 안전망입니다.

## 면접 관점

면접관은 당신이 deadlock은 **설계로 예방하는 것이지 단지 잡는 것이 아님**을 아는지 확인합니다. "재시도"만 짚는 것은 약한 답변입니다 — 훌륭한 답변은 **일관된 lock 순서**와 **짧은 트랜잭션**으로 시작하고, 나머지를 위해 재시도를 더합니다. 흔한 함정: 앱이 deadlock을 감지해야 한다고 가정하는 것; 실무에서는 **DB가 순환을 감지하고 victim을 abort**해줍니다 — 당신의 일은 순서 지정 + 재시도 루프입니다.

**트레이드오프:** 엄격한 순서 지정은 접근 패턴이 동적이거나 테이블에 걸칠 때 어려울 수 있고, 낮은 isolation은 당신이 따져봐야 할 이상 현상(non-repeatable read)의 위험이 있습니다. 재시도 루프는 **idempotent**하고 상한이 있어야 하며, 그렇지 않으면 hot conflict가 재시도 폭풍으로 변합니다. deadlock 예방은 사실 lock 규율 + 제한된 재시도이지 단일 은탄환이 아닙니다.

반드시 깨야 할 순환

전략

면접 관점

관련 질문