როგორ ხელს უშლით deadlock-ებს ათასობით ერთდროული transaction-ით?

Question

IT Interview Practice · Accepted Answer

**აიღეთ lock-ები თანმიმდევრული გლობალური წესრიგით, შეინახეთ transaction-ები მოკლე, დაწიეთ isolation, სადაც უსაფრთხოა, და ხელახლა სცადეთ დამარცხებული, როცა deadlock მაინც ხდება.** deadlock ციკლია: transaction A ფლობს მწკრივ 1-ს და ელოდება მწკრივ 2-ს, ხოლო B ფლობს მწკრივ 2-ს და ელოდება მწკრივ 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 ordering.** თუ ყოველი transaction ყოველთვის ერთი წესრიგით ბლოკავს მწკრივებს (მაგ. primary key-ის ზრდადობით), ციკლი შეუძლებელია — A და B ორივე ჯერ მწკრივ 1-ს იღებს, ამიტომ ერთი უბრალოდ ელოდება. ეს ყველაზე დიდი ბერკეტია. კლასიკური bug: money transfer, რომელიც ანგარიშებს `(from, to)` წესრიგით ბლოკავს, deadlock-ს იწვევს საპირისპირო transfer-თან; ყოველთვის დაბლოკეთ `min(id), max(id)`-ით.
- **მოკლე transaction-ები.** დაიჭირეთ lock-ები რაც შეიძლება მოკლე ხნით — validation, network გამოძახებები და read-ები გააკეთეთ `BEGIN`-ამდე, შემდეგ დაბლოკეთ, ჩაწერეთ და `COMMIT` სწრაფად. გრძელი transaction-ები ციკლებისა და lock wait-ების ფანჯარას აფართოებს.
- **დაწიეთ isolation, სადაც უსაფრთხოა.** `SERIALIZABLE` მეტ/range lock-ს იღებს და მეტ deadlock-ს იწვევს; `READ COMMITTED` (Postgres ნაგულისხმევი) ნაკლებს ბლოკავს. გამოიყენეთ ყველაზე სუსტი isolation, რომელიც მაინც აკმაყოფილებს correctness-ს.
- **Retry deadlock-ზე.** deadlock-ები გარდამავალია. დაიჭირეთ deadlock error (Postgres `40P01`, MySQL `1213`) და ხელახლა სცადეთ მთელი transaction პატარა backoff-ით. გარკვეული contention გარდაუვალია მასშტაბზე, ამიტომ retry უსაფრთხოების ბადეა, არა ordering-ის შემცვლელი.

## ინტერვიუს პერსპექტივა

ინტერვიუერი ამოწმებს, იცით თუ არა, რომ deadlock-ები **დიზაინით არის თავიდან აცილებული, არა უბრალოდ დაჭერილი**. მარტო "retry"-ს დასახელება სუსტი პასუხია — შესანიშნავი პასუხი იწყება **თანმიმდევრული lock ordering-ით** და **მოკლე transaction-ებით**, შემდეგ ამატებს retry-ს ნარჩენისთვის. გავრცელებული ხაფანგი: ვარაუდი, რომ app-მა deadlock-ები უნდა აღმოაჩინოს; პრაქტიკაში **DB აღმოაჩენს ციკლს და აჩერებს victim-ს** თქვენ მაგივრად — თქვენი საქმეა ordering პლუს retry ციკლი.

**ტრეიდ-ოფები:** მკაცრი ordering შეიძლება რთული იყოს, როცა access pattern-ები დინამიურია ან ცხრილებს გადაკვეთს; დაბალი isolation anomaly-ების (non-repeatable read-ები) რისკს ქმნის, რაზეც უნდა იმსჯელოთ. retry ციკლები **idempotent** და შემოსაზღვრული უნდა იყოს, თორემ ცხელი conflict retry storm-ად იქცევა. deadlock prevention სინამდვილეში lock-დისციპლინა პლუს შემოსაზღვრული retry-ია, არა ერთი ვერცხლის ტყვია.

ციკლი, რომელიც უნდა გაწყვიტოთ

სტრატეგიები

ინტერვიუს პერსპექტივა

დაკავშირებული კითხვები