Binlerce eşzamanlı transaction ile deadlock'ları nasıl önlersiniz?

Question

IT Interview Practice · Accepted Answer

**Kilitleri tutarlı bir global sırayla edinin, transaction'ları kısa tutun, güvenli olduğu yerde isolation'ı düşürün ve bir deadlock hala olduğunda kaybedeni yeniden deneyin.** Bir deadlock bir döngüdür: transaction A satır 1'i tutar ve satır 2'yi bekler, B satır 2'yi tutar ve satır 1'i bekler — hiçbiri ilerleyemez, bu yüzden DB birini öldürür.

## Kırmanız gereken döngü

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

## Stratejiler

- **Tutarlı lock ordering.** Her transaction her zaman satırları aynı sırada kilitlerse (örn. artan primary key), bir döngü imkansızdır — A ve B ikisi de önce satır 1'i kapar, bu yüzden biri sadece bekler. Bu en büyük tek kaldıraçtır. Klasik bir bug: hesapları `(from, to)` sırasında kilitleyen bir para transferi, ters transferle deadlock yapar; her zaman `min(id), max(id)` ile kilitleyin.
- **Kısa transaction'lar.** Kilitleri olabildiğince kısa süre tutun — validation, network çağrıları ve okumaları `BEGIN`'den **önce** yapın, sonra hızlıca kilitleyin, yazın ve `COMMIT` edin. Uzun transaction'lar döngüler ve lock bekleyişleri için pencereyi genişletir.
- **Güvenli olduğu yerde isolation'ı düşürün.** `SERIALIZABLE` daha fazla/range lock alır ve daha fazla deadlock yapar; `READ COMMITTED` (Postgres varsayılanı) daha az kilitler. Doğruluğu hala karşılayan en zayıf isolation'ı kullanın.
- **Deadlock'ta yeniden dene.** Deadlock'lar geçicidir. Deadlock hatasını (Postgres `40P01`, MySQL `1213`) yakalayın ve tüm transaction'ı küçük bir backoff ile yeniden deneyin. Ölçekte bir miktar çekişme kaçınılmazdır, bu yüzden yeniden deneme ordering'in yerine değil, bir güvenlik ağıdır.

## Mülakat perspektifi

Mülakatı yapan kişi, deadlock'ların yalnızca yakalanarak değil, **tasarımla önlendiğini** bilip bilmediğinizi kontrol eder. Tek başına "retry" adlandırmak zayıf bir cevaptır — harika cevap **tutarlı lock ordering** ve **kısa transaction'lar** ile başlar, sonra kalan için retry ekler. Yaygın bir tuzak: app'in deadlock'ları tespit etmesi gerektiğini varsaymak; pratikte **DB döngüyü tespit eder ve sizin için bir victim'i abort eder** — sizin işiniz ordering artı bir retry loop'tur.

**Ödünleşimler:** access pattern'ler dinamik olduğunda veya tabloları kapsadığında katı ordering zor olabilir; daha düşük isolation, üzerinde akıl yürütmeniz gereken anomali'ler (non-repeatable read'ler) riski taşır. Retry loop'ları **idempotent** ve sınırlı olmalıdır, yoksa hot bir conflict bir retry storm'una dönüşür. Deadlock önleme gerçekten lock-discipline artı sınırlı bir retry'dir, tek bir silver bullet değil.

Kırmanız gereken döngü

Stratejiler

Mülakat perspektifi

İlgili sorular