Transaction & Concurrency Control

🎯 Mục tiêu bài học

Làm sao để 1000 người cùng mua vé xem phim mà không bị bán trùng ghế?

1. Isolation Levels (Các mức độ cô lập) - Demo

Ví dụ: Tài khoản A có 100$.

a. Read Uncommitted (Mức thấp nhất)

• T1: Trừ A 10$ (Chưa commit, đang chờ). A còn 90$.
• T2: Đọc A. Thấy 90$. (Dirty Read).
• T1: Lỗi -> Rollback. A về lại 100$.
• T2: Dùng số tiền 90$ ma để tính toán -> SAI!

b. Read Committed (Mặc định của Postgres/Oracle)

• T1 trừ tiền nhưng chưa commit. T2 đọc vẫn thấy 100$ (Bản cũ).
• Vấn đề: Non-repeatable Read. T2 đọc lần 1 thấy 100$. T1 commit. T2 đọc lần 2 thấy 90$. (Cùng 1 giao dịch mà đọc 2 lần ra 2 số khác nhau).

c. Repeatable Read (Mặc định của MySQL)

• Đảm bảo đọc lần 1 thấy X, thì đọc lần 2 vẫn thấy X (dù ai đó đã sửa X).
• Dùng cơ chế MVCC (Multi-Version Concurrency Control): Giữ các bản Snapshot cũ.
• Vấn đề: Phantom Read (Bóng ma). T1: Select count(*) from Users -> ra 10. T2: Insert User mới. T1: Select lại -> vẫn ra 10 (RR). Nhưng nếu T1 update cho "tất cả users", nó sẽ update trúng cả User mới của T2!

d. Serializable (Mức cao nhất)

• Khóa toàn bộ bảng (Range Lock). T2 muốn Insert phải chờ T1 xong.
• An toàn tuyệt đối, nhưng chậm như rùa. Ít dùng.

2. Distributed Transactions (Giao dịch phân tán)

Chuyển tiền từ Ngân hàng A (Database A) sang Ngân hàng B (Database B).

2PC (Two-Phase Commit)

• Phase 1 (Prepare): Coordinator hỏi "A sẵn sàng trừ chưa?", "B sẵn sàng cộng chưa?". Cả 2 lock tài nguyên và trả lời "Yes/No".
• Phase 2 (Commit): Nếu cả 2 Yes -> Gửi lệnh "Commit". Nếu 1 thằng No -> Gửi lệnh "Rollback".
• Nhược điểm: Chặn (Blocking). Nếu Coordinator chết giữa chừng, A và B bị treo lock vĩnh viễn.

SAGA Pattern (Microservices)

• Chia transaction to thành chuỗi các transaction nhỏ cục bộ (T1 -> T2 -> T3).
• Nếu T2 lỗi -> Chạy bù (Compensating Transaction) C1 để hoàn tác T1.
• Vd: T1 (Trừ tiền) -> T2 (Đặt vé - Lỗi) -> C1 (Hoàn tiền). Dữ liệu có lúc không nhất quán (Eventual Consistency) nhưng hệ thống không bị treo.