Làm sao ngăn deadlock với hàng nghìn transaction đồng thời?

Question

IT Interview Practice · Accepted Answer

**Giành lock theo một thứ tự toàn cục nhất quán, giữ transaction ngắn, hạ isolation ở nơi an toàn, và retry bên thua khi deadlock vẫn xảy ra.** Deadlock là một chu trình: transaction A giữ row 1 và chờ row 2, còn B giữ row 2 và chờ row 1 — không bên nào tiến được, nên DB giết một bên.

## Chu trình bạn phải phá vỡ

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

## Các chiến lược

- **Thứ tự lock nhất quán.** Nếu mọi transaction luôn lock các dòng theo cùng một thứ tự (vd. primary key tăng dần), chu trình là không thể — A và B đều giành row 1 trước, nên một bên chỉ việc chờ. Đây là đòn bẩy lớn nhất. Một bug kinh điển: chuyển tiền lock account theo thứ tự `(from, to)` sẽ deadlock với lệnh chuyển ngược chiều; hãy luôn lock theo `min(id), max(id)`.
- **Transaction ngắn.** Giữ lock ít thời gian nhất có thể — làm validation, network call và các lần đọc **trước** `BEGIN`, rồi lock, write và `COMMIT` thật nhanh. Transaction dài mở rộng cửa sổ cho chu trình và chờ lock.
- **Hạ isolation ở nơi an toàn.** `SERIALIZABLE` lấy nhiều lock/range lock hơn nên deadlock nhiều hơn; `READ COMMITTED` (mặc định Postgres) lock ít hơn. Dùng mức isolation yếu nhất mà vẫn đảm bảo đúng.
- **Retry khi deadlock.** Deadlock chỉ thoáng qua. Bắt lỗi deadlock (Postgres `40P01`, MySQL `1213`) và retry cả transaction với backoff nhỏ. Ở quy mô lớn một chút tranh chấp là không tránh khỏi, nên retry là lưới an toàn, không thay thế cho việc sắp thứ tự.

## Góc nhìn phỏng vấn

Người phỏng vấn kiểm tra xem bạn có biết deadlock được **ngăn bằng thiết kế, không chỉ bắt lỗi**. Chỉ nêu "retry" là câu trả lời yếu — câu xuất sắc dẫn đầu bằng **thứ tự lock nhất quán** và **transaction ngắn**, rồi thêm retry cho phần còn dư. Bẫy thường gặp: tưởng ứng dụng phải tự phát hiện deadlock; thực tế **DB phát hiện chu trình và abort một victim** giúp bạn — việc của bạn là sắp thứ tự cộng một vòng retry.

**Đánh đổi:** thứ tự nghiêm ngặt khó áp dụng khi access pattern động hoặc trải nhiều bảng; hạ isolation gây nguy cơ anomaly (non-repeatable read) mà bạn phải cân nhắc. Vòng retry phải **idempotent** và có giới hạn, nếu không một điểm nóng tranh chấp biến thành retry storm. Ngăn deadlock thực chất là kỷ luật lock cộng một retry có giới hạn, không phải một viên đạn bạc duy nhất.

Chu trình bạn phải phá vỡ

Các chiến lược

Góc nhìn phỏng vấn

Câu hỏi liên quan