Πώς αποτρέπετε deadlocks με χιλιάδες ταυτόχρονα transactions;

Question

IT Interview Practice · Accepted Answer

**Αποκτήστε locks με μια συνεπή global σειρά, κρατήστε τα transactions σύντομα, χαμηλώστε το isolation όπου είναι ασφαλές, και κάντε retry τον χαμένο όταν ένα deadlock παρόλα αυτά συμβεί.** Ένα deadlock είναι ένας κύκλος: το transaction A κρατά τη row 1 και περιμένει τη row 2, ενώ το B κρατά τη row 2 και περιμένει τη row 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)
```

## Στρατηγικές

- **Consistent lock ordering.** Αν κάθε transaction κλειδώνει πάντα τις rows με την ίδια σειρά (π.χ. αύξον primary key), ένας κύκλος είναι αδύνατος — τα A και B αρπάζουν και τα δύο τη row 1 πρώτα, οπότε το ένα απλώς περιμένει. Αυτός είναι ο μεγαλύτερος μοχλός. Ένα κλασικό bug: ένα money transfer που κλειδώνει λογαριασμούς σε σειρά `(from, to)` κάνει deadlock με το αντίστροφο transfer· κλειδώνετε πάντα κατά `min(id), max(id)`.
- **Σύντομα transactions.** Κρατήστε τα locks για όσο το δυνατόν λιγότερο — κάντε validation, network calls, και reads **πριν** το `BEGIN`, μετά lock, write, και `COMMIT` γρήγορα. Τα long transactions διευρύνουν το παράθυρο για κύκλους και lock waits.
- **Χαμηλώστε το isolation όπου είναι ασφαλές.** Το `SERIALIZABLE` παίρνει περισσότερα/range locks και κάνει deadlock περισσότερο· το `READ COMMITTED` (Postgres default) κλειδώνει λιγότερο. Χρησιμοποιήστε το ασθενέστερο isolation που εξακολουθεί να καλύπτει την ορθότητα.
- **Retry στο deadlock.** Τα deadlocks είναι παροδικά. Πιάστε το deadlock error (Postgres `40P01`, MySQL `1213`) και κάντε retry ολόκληρο το transaction με μικρό backoff. Κάποια contention είναι αναπόφευκτη σε κλίμακα, οπότε το retry είναι δίχτυ ασφαλείας, όχι υποκατάστατο του ordering.

## Οπτική συνέντευξης

Ο συνεντευκτής ελέγχει αν ξέρετε ότι τα deadlocks **αποτρέπονται με σχεδιασμό, όχι απλώς πιάνονται**. Το να κατονομάζετε μόνο το "retry" είναι αδύναμη απάντηση — η εξαιρετική απάντηση ξεκινά με **consistent lock ordering** και **σύντομα transactions**, μετά προσθέτει retry για το υπόλοιπο. Μια συνηθισμένη παγίδα: να θεωρείτε ότι η app πρέπει να ανιχνεύει deadlocks· στην πράξη η **βάση ανιχνεύει τον κύκλο και ματαιώνει ένα θύμα** για εσάς — η δουλειά σας είναι ordering συν ένα retry loop.

**Trade-offs:** το αυστηρό ordering μπορεί να είναι δύσκολο όταν τα access patterns είναι δυναμικά ή εκτείνονται σε πίνακες· το χαμηλότερο isolation ρισκάρει anomalies (non-repeatable reads) που πρέπει να συλλογιστείτε. Τα retry loops πρέπει να είναι **idempotent** και capped, αλλιώς ένα hot conflict γίνεται retry storm. Η αποτροπή deadlock είναι πραγματικά lock-discipline συν ένα φραγμένο retry, όχι μια μοναδική ασημένια σφαίρα.

Ο κύκλος που πρέπει να σπάσετε

Στρατηγικές

Οπτική συνέντευξης

Σχετικές ερωτήσεις