Ta yaya za ka hana deadlocks da dubban concurrent transactions?

Question

IT Interview Practice · Accepted Answer

**Ka samo locks a consistent global order, ka ajiye transactions gajeru, ka rage isolation inda yayi lafiya, kuma ka retry mai rashin nasara lokacin da deadlock har yanzu ya faru.** Deadlock cycle ne: transaction A yana riƙe row 1 kuma yana jiran row 2, yayin da B ke riƙe row 2 kuma yana jiran row 1 — babu wanda zai iya ci gaba, don haka DB yana kashe ɗaya.

## Cycle da dole ka karya

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

## Dabaru

- **Consistent lock ordering.** Idan kowace transaction koyaushe tana lock rows a same order (misali ascending primary key), cycle ba zai yiwu ba — A da B duk suna ƙwace row 1 da farko, don haka ɗaya kawai yana jira. Wannan shi ne mafi girman lever guda ɗaya. Bug na gargajiya: money transfer da ke lock accounts a `(from, to)` order yana deadlock da reverse transfer; koyaushe lock da `min(id), max(id)`.
- **Short transactions.** Riƙe locks na ɗan lokaci gwargwadon iko — yi validation, network calls, da reads **kafin** `BEGIN`, sannan lock, write, da `COMMIT` da sauri. Long transactions suna faɗaɗɗa window ga cycles da lock waits.
- **Lower isolation inda yayi lafiya.** `SERIALIZABLE` yana ɗaukar more/range locks kuma yana deadlock sosai; `READ COMMITTED` (Postgres default) yana lock kaɗan. Yi amfani da mafi rauni isolation da har yanzu ke biyan correctness.
- **Retry a deadlock.** Deadlocks transient ne. Kama deadlock error (Postgres `40P01`, MySQL `1213`) kuma ka retry dukan transaction da small backoff. Wasu contention ba za a iya gujewa ba a sikeli, don haka retry safety net ne, ba maye gurbin ordering ba.

## Ra'ayin hira

Mai yin hirar yana bincike ko ka san ana **hana deadlocks ta design, ba kama kawai ba**. Ambaton "retry" kaɗai amsa mai rauni ce — amsa mai kyau sosai tana jagoranci da **consistent lock ordering** da **short transactions**, sannan tana ƙara retry don ragowa. Tarkon gama gari: ɗauka app dole ya gano deadlocks; a aikace **DB yana gano cycle kuma yana abort victim** gare ka — aikinka shi ne ordering tare da retry loop.

**Sulhu:** strict ordering na iya zama mai wuya lokacin da access patterns suke dynamic ko span tables; lower isolation yana haɗarin anomalies (non-repeatable reads) da dole ka yi tunani a kai. Retry loops dole su zama **idempotent** kuma capped, ko hot conflict yana zama retry storm. Deadlock prevention da gaske lock-discipline ne tare da bounded retry, ba single silver bullet ba.

Cycle da dole ka karya

Dabaru

Ra'ayin hira

Tambayoyi masu alaƙa