Database bị Deadlock làm treo worker: cách chẩn đoán và khắc phục

Trong các hệ thống xử lý dữ liệu bất đồng bộ như hàng đợi đơn hàng, giao dịch thanh toán hoặc đồng bộ tồn kho, các tiến trình worker (như Celery, Laravel Queue, BullMQ hay Go worker) thường chạy song song để tăng tốc độ xử lý.

Vào các khung giờ cao điểm khi nhiều worker cùng thao tác đồng thời trên một tập dữ liệu, hiện tượng hàng đợi bị dồn ứ bắt đầu xuất hiện. Các worker không hề bị sập tiến trình, CPU và RAM của máy chủ database vẫn ở mức an toàn (hoặc có thể kéo theo nguy cơ cạn kiệt kết nối Too many connections nếu số lượng worker mở pool lớn), nhưng thời gian hoàn thành các job bị kéo dài bất thường hoặc job liên tục bị đẩy vào hàng đợi thất bại (Failed Jobs Queue).

Kiểm tra file nhật ký của ứng dụng hoặc error log của cơ sở dữ liệu thường xuất hiện lỗi:

• Trên MySQL: Error 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
• Trên PostgreSQL: ERROR: deadlock detected - Process 12450 waits for ShareLock on transaction 8920...

Tình trạng này bắt nguồn từ hiện tượng Khóa chết (Deadlock) giữa các giao dịch trong cơ sở dữ liệu. Nếu không nắm rõ cơ chế khóa dòng và cách chẩn đoán từ log hệ quản trị, việc khởi động lại worker chỉ mang tính tạm thời và sự cố sẽ lặp lại ngay khi có lưu lượng giao dịch tăng nhẹ.

Vòng lặp phụ thuộc chéo (Circular Wait) giữa hai giao dịch đồng thời trên cơ sở dữ liệu.

Bản chất của Deadlock và sự khác biệt với Lock Wait

Để chẩn đoán chính xác, bạn cần phân biệt rõ giữa hai khái niệm: Chờ khóa (Lock Wait) và Khóa chết (Deadlock) theo đặc tả tại MySQL Documentation - InnoDB Deadlocks:

1. Hiện tượng chờ khóa thông thường (Lock Wait)

Trong các giao dịch thực thi lệnh UPDATE, DELETE hoặc SELECT ... FOR UPDATE, cơ sở dữ liệu sẽ khóa (lock) các dòng dữ liệu liên quan để đảm bảo tính toàn vẹn:

• Nếu Giao dịch A đang sửa đổi dòng dữ liệu có ID = 1 và chưa hoàn tất (COMMIT), Giao dịch B muốn sửa dòng ID = 1 sẽ phải tạm dừng và xếp hàng chờ.
• Ngay khi Giao dịch A kết thúc bằng lệnh COMMIT hoặc ROLLBACK, khóa được giải phóng và Giao dịch B tiếp tục chạy bình thường.
• Đây là cơ chế vận hành chuẩn mực để tránh xung đột ghi đè dữ liệu. Giao dịch chỉ bị lỗi nếu thời gian chờ vượt quá ngưỡng cấu hình (ví dụ innodb_lock_wait_timeout mặc định là 50 giây).

2. Hiện tượng khóa chết (Deadlock)

Deadlock là trạng thái bế tắc khi xuất hiện sự phụ thuộc vòng tròn (Circular Dependency) giữa hai hoặc nhiều giao dịch:

• Giao dịch A đang giữ khóa trên Dòng 1 và yêu cầu khóa tiếp Dòng 2.
• Cùng lúc đó, Giao dịch B đang giữ khóa trên Dòng 2 và lại yêu cầu khóa tiếp Dòng 1.

Trong kịch bản này, cả hai giao dịch đều chờ nhau và không thể tự kết thúc.

Để bảo vệ hệ thống không bị treo, bộ máy cơ sở dữ liệu (như InnoDB Engine trên MySQL hoặc Lock Manager trên PostgreSQL) tích hợp thuật toán phát hiện chu trình đồ thị khóa. Ngay khi phát hiện bế tắc, database sẽ chọn một trong hai giao dịch làm đối tượng hủy bỏ (Victim), buộc giao dịch đó phải rollback ngay lập tức và trả về mã lỗi Deadlock cho ứng dụng, đồng thời giải phóng khóa để giao dịch còn lại tiếp tục chạy.

Bước 1: Trích xuất thông tin chi tiết Deadlock từ Database

Khi xảy ra lỗi Deadlock, hệ quản trị cơ sở dữ liệu luôn lưu lại thông tin chi tiết về các câu lệnh SQL và các dòng dữ liệu bị xung đột. Việc đọc đúng thông tin này là căn cứ duy nhất để bạn biết đoạn mã nguồn nào trong ứng dụng đang gây ra lỗi.

1. Phân tích mục Deadlock trên MySQL (InnoDB Engine)

Trên MySQL, bạn chạy lệnh sau trong console dòng lệnh để xem vụ deadlock gần nhất:

SHOW ENGINE INNODB STATUS\G

Tìm đến phần có tiêu đề ------------------------ LATEST DETECTED DEADLOCK ------------------------. Phần này cung cấp báo cáo chi tiết về hai giao dịch xung đột:

*** (1) TRANSACTION:
TRANSACTION 18920, ACTIVE 2 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 1128, 2 row lock(s)
MySQL thread id 124, OS thread handle 1402, query id 8901 localhost app_user updating
UPDATE orders SET status = 'processing' WHERE id = 101

*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 42 page no 8 n bits 80 index PRIMARY of table `shop`.`orders` 
trx id 18920 lock_mode X locks rec but not gap waiting

*** (2) TRANSACTION:
TRANSACTION 18921, ACTIVE 1 sec starting index read
mysql tables in use 1, locked 1
4 lock struct(s), heap size 1128, 3 row lock(s)
MySQL thread id 125, OS thread handle 1403, query id 8905 localhost app_user updating
UPDATE orders SET status = 'cancelled' WHERE id = 102

*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 42 page no 8 n bits 80 index PRIMARY of table `shop`.`orders` 
trx id 18921 lock_mode X locks rec but not gap

*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 42 page no 8 n bits 80 index PRIMARY of table `shop`.`orders` 
trx id 18921 lock_mode X locks rec but not gap waiting

*** WE ROLL BACK TRANSACTION (1)

Cách đọc báo cáo:

• TRANSACTION (1): Giao dịch thứ nhất đang chạy câu lệnh UPDATE orders ... WHERE id = 101. Mục WAITING FOR THIS LOCK cho thấy nó đang chờ khóa trên bản ghi của bảng orders.
• TRANSACTION (2): Giao dịch thứ hai đang chạy câu lệnh UPDATE orders ... WHERE id = 102. Mục HOLDS THE LOCK(S) cho thấy nó đang giữ chính khóa mà Giao dịch 1 đang chờ, đồng thời mục WAITING FOR THIS LOCK cho thấy Giao dịch 2 lại đang chờ khóa mà Giao dịch 1 đang giữ.
• WE ROLL BACK TRANSACTION (1): InnoDB quyết định rollback Giao dịch 1 vì giao dịch này có số lượng dòng bị thay đổi ít hơn (chi phí rollback thấp hơn).

2. Bật ghi nhật ký toàn bộ Deadlock trên MySQL

Theo mặc định, lệnh SHOW ENGINE INNODB STATUS chỉ lưu lại duy nhất 1 vụ deadlock gần nhất. Nếu hệ thống có nhiều vụ deadlock xảy ra liên tiếp, thông tin các vụ trước sẽ bị ghi đè.

Bạn nên bật tham số sau để database ghi lại toàn bộ các vụ deadlock vào error log:

-- Bật ghi log toàn bộ sự kiện deadlock ngay lập tức trên bộ nhớ
SET GLOBAL innodb_print_all_deadlocks = 1;

Để giữ cấu hình này sau khi restart, thêm vào file /etc/mysql/my.cnf:

[mysqld]
innodb_print_all_deadlocks = 1

Sau khi bật, toàn bộ báo cáo deadlock sẽ được ghi chi tiết vào file /var/log/mysql/error.log.

3. Kiểm tra thông tin Deadlock trên PostgreSQL

Trên PostgreSQL, thông tin deadlock được ghi thẳng vào log của máy chủ tại /var/log/postgresql/postgresql-16-main.log (tùy phiên bản).

Để đảm bảo database ghi nhận đầy đủ ngữ cảnh của câu truy vấn khi bị khóa, bạn kiểm tra và bật hai tham số sau trong file postgresql.conf:

# Ghi log khi thời gian chờ khóa vượt quá 1 giây
log_lock_waits = on

# Thiết lập thời gian phát hiện deadlock (mặc định 1 giây)
deadlock_timeout = 1s

Khi có sự cố, log của PostgreSQL sẽ hiển thị chi tiết dòng lệnh của cả hai tiến trình (PID), loại khóa (ShareLock hay ExclusiveLock), và bảng dữ liệu bị xung đột.

Bước 2: Phân tích 3 nguyên nhân phổ biến nhất trong ứng dụng

Dựa vào báo cáo log trích xuất ở Bước 1, bạn có thể đối chiếu vào 3 kịch bản lỗi kiến trúc ứng dụng thường gặp nhất dưới đây:

1. Ngược thứ tự cập nhật bản ghi giữa các tiến trình worker

Đây là nguyên nhân kinh điển nhất chiếm phần lớn các vụ deadlock trong các hệ thống xử lý giao dịch.

Giả sử bạn có chức năng chuyển tiền giữa hai tài khoản ngân hàng, hoặc cập nhật tồn kho khi gom đơn hàng từ nhiều kho khác nhau:

• Worker 1 (chuyển tiền từ Tài khoản A sang B):

1. UPDATE accounts SET balance = balance - 100 WHERE id = 'A'; (Khóa bản ghi A)
2. UPDATE accounts SET balance = balance + 100 WHERE id = 'B'; (Cần khóa bản ghi B)

• Worker 2 (chuyển tiền từ Tài khoản B sang A):

1. UPDATE accounts SET balance = balance - 50 WHERE id = 'B'; (Khóa bản ghi B)
2. UPDATE accounts SET balance = balance + 50 WHERE id = 'A'; (Cần khóa bản ghi A)

Nếu hai worker này chạy đồng thời tại cùng một thời điểm:

• Worker 1 giữ A và chờ B.
• Worker 2 giữ B và chờ A.
• Vòng lặp khóa chết xuất hiện ngay lập tức.

2. Thiếu Index khiến Database kích hoạt Gap Lock hoặc khóa toàn bảng

Trên engine InnoDB của MySQL ở mức cô lập mặc định REPEATABLE READ, khi bạn chạy một câu lệnh cập nhật hoặc xóa dữ liệu:

• Nếu cột trong mệnh đề WHERE có đánh chỉ mục (Index): InnoDB chỉ đặt khóa dòng (Record Lock) trên đúng các bản ghi thỏa mãn điều kiện.
• Nếu cột trong mệnh đề WHERE KHÔNG có Index: InnoDB buộc phải quét toàn bộ bảng (Table Scan). Trong quá trình này, InnoDB không chỉ khóa tất cả các dòng hiện có mà còn đặt Gap Lock (khóa khoảng trống giữa các bản ghi) và Next-Key Lock trên toàn bộ bảng.

Ví dụ: Hai worker cập nhật hai đơn hàng hoàn toàn khác nhau:

• Worker 1: UPDATE orders SET status = 'paid' WHERE tracking_code = 'VN123';
• Worker 2: UPDATE orders SET status = 'paid' WHERE tracking_code = 'VN456';

Nếu cột tracking_code chưa được đánh index, cả hai câu lệnh đều quét và đặt Gap Lock trên cùng một dải dữ liệu của bảng orders, dẫn đến tình trạng tranh chấp khóa và gây ra deadlock dù hai đơn hàng không liên quan gì đến nhau.

3. Giao dịch kéo dài do kẹp các tác vụ I/O hoặc gọi API bên ngoài

Một sai lầm rất phổ biến trong lập trình backend là mở transaction database quá sớm và bao bọc toàn bộ logic nghiệp vụ bên trong khối giao dịch:

BẮT ĐẦU TRANSACTION
  ├── 1. Khóa dòng dữ liệu trong DB (SELECT ... FOR UPDATE)
  ├── 2. Gọi API cổng thanh toán bên thứ ba (Mất từ 2 đến 5 giây)
  ├── 3. Gửi email xác nhận hoặc thông báo Webhook
  └── 4. Cập nhật trạng thái và COMMIT TRANSACTION

Trong suốt thời gian chờ phản hồi từ API mạng (bước 2 và 3), khóa trên các dòng dữ liệu ở bước 1 vẫn bị giữ chặt. Bất kỳ worker nào khác cần thao tác trên dòng dữ liệu này đều bị nghẽn lại, làm tăng nguy cơ giao cắt khóa với các tiến trình khác theo cấp số nhân.

Bước 3: Các biện pháp xử lý và tối ưu hóa ở tầng ứng dụng

Khác với các lỗi về tài nguyên phần cứng, Deadlock chủ yếu bắt nguồn từ thiết kế luồng dữ liệu của ứng dụng. Để hạn chế sự cố này, bạn cần áp dụng các nguyên tắc kỹ thuật sau:

1. Chuẩn hóa thứ tự cập nhật bản ghi theo khóa chính

Đây là nguyên tắc quan trọng: Mọi tiến trình worker trong toàn bộ hệ thống phải luôn khóa các bản ghi theo cùng một thứ tự sắp xếp duy nhất (thường là sắp xếp tăng dần theo ID hoặc khóa chính).

Áp dụng cho ví dụ chuyển tiền giữa hai tài khoản A và B ở bước trước:

• Luôn so sánh hai ID trước khi thực hiện khóa:
• Nếu ID A < ID B: Khóa A trước, sau đó mới khóa B.
• Dù là luồng chuyển từ A sang B hay từ B sang A, thứ tự khóa trên database vẫn luôn là A trước rồi đến B.

Khi cả hai worker cùng tuân thủ quy tắc khóa A trước rồi đến B:

• Worker nào lấy được khóa A trước sẽ thực thi trọn vẹn và khóa tiếp B.
• Worker đến sau sẽ tạm dừng chờ tại A (chuyển thành Lock Wait thông thường) thay vì giữ B để tạo ra vòng lặp bế tắc. Hiện tượng Deadlock không thể xuất hiện.

Quy tắc tương tự áp dụng cho các câu lệnh cập nhật nhiều dòng: Khi chạy UPDATE ... WHERE id IN (...), hãy luôn sắp xếp mảng ID theo thứ tự tăng dần trước khi truyền vào câu lệnh SQL.

2. Thu hẹp phạm vi và thời gian sống của Transaction

Transaction càng ngắn, thời gian giữ khóa càng ít và xác suất xảy ra xung đột khóa càng thấp:

• Đưa các tác vụ I/O ra ngoài: Không gọi API mạng, không gửi email, không xử lý file và không tính toán thuật toán nặng bên trong khối BEGIN ... COMMIT. Hãy chuẩn bị sẵn toàn bộ dữ liệu cần thiết trước khi bắt đầu transaction.
• Mở transaction muộn nhất có thể: Chỉ bắt đầu transaction ngay trước câu lệnh ghi đầu tiên và thực thi lệnh COMMIT ngay sau câu lệnh ghi cuối cùng.

3. Thiết lập cơ chế tự động thử lại (Retry) có độ trễ ngẫu nhiên

Trong các hệ thống phân tán, dù bạn tối ưu mã nguồn cẩn thận, việc hai worker cùng chạm vào một tài nguyên vào cùng một mili-giây vẫn có thể xảy ra. Do đó, mã nguồn của worker nên có cơ chế bắt lỗi Deadlock và tự động thử lại (Retry Logic); xem thêm nguyên tắc xây dựng tại bài Xử lý khi workflow tự động bị lỗi: retry, dừng an toàn và phục hồi:

# Ví dụ xử lý Deadlock trong Python / Worker
import time
import random

MAX_RETRIES = 3

for attempt in range(MAX_RETRIES):
    try:
        with database.transaction():
            # Thực thi các câu lệnh cập nhật dữ liệu
            update_order_and_inventory()
            break  # Thành công, thoát vòng lặp
    except OperationalError as e:
        # Kiểm tra mã lỗi Deadlock (MySQL: 1213, Postgres: 40P01)
        if "deadlock" in str(e).lower() and attempt < MAX_RETRIES - 1:
            # Nghỉ ngẫu nhiên (Exponential Backoff + Jitter) để tránh xung đột lại
            sleep_time = (2 ** attempt * 0.1) + random.uniform(0.05, 0.1)
            time.sleep(sleep_time)
        else:
            raise e

Việc thêm độ trễ ngẫu nhiên (Jitter) khi retry là cần thiết: Nó giúp hai worker không cùng thức dậy và tranh chấp khóa tại cùng một thời điểm sau khi bị rollback.

Bước 4: Tinh chỉnh tham số Database để hạn chế treo Worker

Bên cạnh việc tối ưu mã nguồn, bạn cần cấu hình các giới hạn thời gian chờ (timeout) trên cơ sở dữ liệu để ngăn chặn tình trạng worker bị treo vĩnh viễn khi gặp sự cố chờ khóa:

1. Tinh chỉnh thời gian chờ khóa trên MySQL (InnoDB)

Mặc định, thông số innodb_lock_wait_timeout trên MySQL là 50 giây. Với một worker xử lý nền, việc bị treo suốt 50 giây trước khi nhận thông báo lỗi là quá lâu, làm hàng đợi tích tụ hàng nghìn job bị nghẽn phía sau.

Bạn nên hạ giá trị này xuống mức hợp lý trong file /etc/mysql/my.cnf:

[mysqld]
# Giảm thời gian chờ khóa dòng xuống 10 giây (hoặc 5 giây tùy nghiệp vụ)
innodb_lock_wait_timeout = 10

# Sử dụng mức cô lập READ COMMITTED để giảm thiểu Gap Lock (nếu ứng dụng hỗ trợ)
transaction_isolation = READ-COMMITTED

Áp dụng tạm thời ngay trên bộ nhớ:

SET GLOBAL innodb_lock_wait_timeout = 10;

Lưu ý về mức cô lập giao dịch: Việc chuyển mức cô lập từ REPEATABLE READ sang READ COMMITTED là một kỹ thuật phổ biến trong các hệ thống OLTP có tải cao. Ở mức READ COMMITTED, InnoDB chỉ đặt khóa trên các dòng thực tế và loại bỏ hầu hết các Gap Lock, giúp giảm thiểu đáng kể các vụ deadlock do quét khoảng trống dữ liệu gây ra.

2. Tinh chỉnh thời gian phát hiện Deadlock trên PostgreSQL

PostgreSQL có bộ phát hiện deadlock rất nhạy bén, được điều khiển bởi tham số deadlock_timeout (mặc định là 1 giây) trong postgresql.conf (tham khảo tài liệu PostgreSQL Documentation - Explicit Locking & Deadlocks):

# Thời gian chờ trước khi kích hoạt thuật toán phát hiện deadlock
deadlock_timeout = 1s

# Giới hạn thời gian tối đa cho bất kỳ câu lệnh SQL nào (ví dụ 15 giây)
statement_timeout = 15000

# Tự động ngắt transaction nhàn rỗi sau 30 giây
idle_in_transaction_session_timeout = 30000

Tham số statement_timeout = 15000 (15 giây) là chốt chặn quan trọng: Nó đảm bảo không có bất kỳ câu truy vấn nào của worker được phép chạy quá 15 giây, ngăn chặn tình trạng một câu lệnh bị treo giữ khóa làm tê liệt toàn bộ hệ thống.

Tóm tắt quy trình kiểm tra và xử lý khi Worker bị treo do Deadlock

Khi phát hiện hàng đợi worker bị dồn ứ bất thường, bạn tiến hành điều tra theo 4 bước:

1. Trích xuất bằng chứng: Chạy SHOW ENGINE INNODB STATUS (MySQL) hoặc đọc file log PostgreSQL để lấy chi tiết hai câu lệnh SQL và các dòng ID bị xung đột.
2. Kích hoạt ghi log liên tục: Bật innodb_print_all_deadlocks = 1 hoặc log_lock_waits = on để theo dõi tần suất và các điểm nóng tranh chấp khóa.
3. Sửa đổi mã nguồn ứng dụng:

• Đảm bảo tất cả worker cập nhật các bản ghi theo cùng một thứ tự sắp xếp khóa chính tăng dần.
• Bổ sung Index cho các cột trong mệnh đề WHERE để tránh Gap Lock.
• Rút ngắn transaction và triển khai cơ chế Retry với độ trễ ngẫu nhiên (Jitter).

1. Thiết lập giới hạn an toàn: Hạ innodb_lock_wait_timeout về 5-10 giây và đặt statement_timeout để giải phóng worker kịp thời khi có xung đột.

Để theo dõi sát sao tình trạng tranh chấp khóa và kịp thời phát hiện các câu truy vấn chậm trên hệ thống, bạn nên đưa chỉ số lock wait vào hệ thống giám sát định kỳ; tham khảo chi tiết tại bài Monitoring Database: các chỉ số quan trọng cần theo dõi.