Bẫy Cấp Độ Cô Lập Giao Dịch & Tranh Chấp Khóa (Lock Contention) Trong CSDL Quan Hệ

Phổ Bậc Cấp Độ Cô Lập (ACID Isolation Levels)

Trong tiêu chuẩn ANSI/ISO SQL, bốn cấp độ cô lập giao dịch được định nghĩa nhằm cân bằng giữa tính toàn vẹn dữ liệu và thông lượng xử lý đồng thời (Concurrency):

1. Read Uncommitted: Cho phép đọc dữ liệu bẩn chưa commit (Dirty Read). Hầu hết các hệ thống hiện đại đều không khuyến khích mức này.
2. Read Committed (Mặc định trong PostgreSQL): Mỗi câu lệnh trong transaction chỉ nhìn thấy dữ liệu đã commit trước khi câu lệnh đó bắt đầu chạy. Ngăn chặn Dirty Read nhưng vẫn cho phép Non-repeatable Read (đọc lại cùng dòng dữ liệu trong 1 transaction thấy giá trị khác) và Phantom Read.
3. Repeatable Read (Mặc định trong MySQL InnoDB): Toàn bộ transaction chỉ nhìn thấy một snapshot dữ liệu duy nhất tại thời điểm transaction khởi tạo. Ngăn chặn Non-repeatable Read.
4. Serializable: Mức cô lập nghiêm ngặt nhất, bảo đảm kết quả thực thi đồng thời của các transaction tương đương như khi chạy tuần tự từng transaction một.

Bài Toán Flash Sale: Trừ Tồn Kho Hàng Triệu Khách Hàng Đồng Thời

Xét bài toán kinh điển: Mặt hàng iPhone chỉ còn 10 sản phẩm, nhưng có 5,000 khách hàng đồng thời bấm "Đặt Mua" trong vòng 1 giây.

sql(6 dòng)
Sao chép
-- CODE NGUY HIỂM: Gây bán âm hàng (Inventory Overselling)
-- Transaction 1 & 2 cùng đọc stock = 10 tại cùng thời điểm
SELECT stock FROM products WHERE id = 101;

-- Cả hai đều thỏa mãn điều kiện stock > 0 và tiến hành trừ
UPDATE products SET stock = stock - 1 WHERE id = 101;

Cách Xử Lý 1: Pessimistic Locking Với SELECT FOR UPDATE

sql(8 dòng)
Sao chép
BEGIN;
-- Khóa độc quyền (Row-Exclusive Lock) trên dòng sản phẩm
SELECT stock FROM products WHERE id = 101 FOR UPDATE;

-- Kiểm tra logic nghiệp vụ trong tầng application
-- Nếu stock >= qty:
UPDATE products SET stock = stock - 1 WHERE id = 101;
COMMIT;

Điểm yếu nghiêm trọng: Khi có 5,000 kết nối cùng tranh chấp hàng, 4,999 connection còn lại sẽ bị treo trạng thái chờ (Lock Wait). Hàng loạt worker goroutine/thread bị khóa nghẽn, làm cạn kiệt Connection Pool và khiến toàn bộ các API khác của hệ thống chết đứng theo.

Giải Pháp Hiện Đại: Khóa Không Chờ & Khóa Lạc Quan (Optimistic)

1. SELECT FOR UPDATE NOWAIT / SKIP LOCKED

Nếu không thể lấy khóa ngay lập tức, hãy từ chối hoặc bỏ qua dòng đó thay vì xếp hàng chờ:

sql(2 dòng)
Sao chép
-- Báo lỗi ngay lập tức nếu dòng đang bị transaction khác xử lý
SELECT stock FROM products WHERE id = 101 FOR UPDATE NOWAIT;

Đối với hệ thống hàng đợi công việc (Job Queue / Task Consumer), sử dụng SKIP LOCKED:

sql(5 dòng)
Sao chép
-- Đọc dòng tiếp theo chưa bị ai khóa, hoàn toàn không gây nghẽn
SELECT * FROM background_tasks 
WHERE status = 'PENDING' 
LIMIT 1 
FOR UPDATE SKIP LOCKED;

2. Nguyên Tử Hóa Trực Tiếp Trên SQL (Atomic Single-Query Update)

Không cần đọc trước, hãy thực hiện kiểm tra và cập nhật trong một lệnh duy nhất:

sql(4 dòng)
Sao chép
UPDATE products 
SET stock = stock - 1 
WHERE id = 101 AND stock >= 1
RETURNING stock;

Nếu số dòng bị ảnh hưởng (Rows Affected) trả về bằng 0, ứng dụng biết ngay mặt hàng đã hết hàng và phản hồi cho khách mà không tốn công đoạn lock kéo dài.

3. Kỹ Thuật Sharding Tồn Kho (Inventory Bucket Sharding)

Để cho phép hàng nghìn transaction ghi đồng thời mà không nghẽn trên 1 dòng duy nhất, ta chia 1 mặt hàng thành $N$ bucket ngẫu nhiên:

sql(7 dòng)
Sao chép
-- Bảng kho chia nhỏ thành 10 buckets
-- product_id = 101, bucket_id từ 1 đến 10, mỗi bucket lưu 1 phần số lượng
UPDATE product_inventory_buckets 
SET stock = stock - 1 
WHERE product_id = 101 
  AND bucket_id = (SELECT floor(random() * 10 + 1)::int) 
  AND stock >= 1;

Tranh chấp khóa trên hàng được phân tán giảm đi 10 lần, tăng thông lượng ghi lên tương ứng.

Bảng Đánh Giá Các Phương Pháp