Hiểu Sâu Về ACID Trong Database: Khi Lý Thuyết Cứu Sống Những Pha Bug "Toát Mồ Hôi"

Chào anh em Viblo! 👋

Hồi mới chập chững làm quen với Database, mình cứ nghĩ đơn giản là: "Cứ INSERT, UPDATE, DELETE thành công là xong". Cho đến một ngày đẹp trời, hệ thống tài chính của dự án gặp một con bug đi vào lòng đất: Tiền trong tài khoản người gửi đã bị trừ, nhưng người nhận thì... không thấy tiền đâu. Khách hàng la ó, team thì cuống cuồng lục log trong đêm.

Đó là lúc mình nhận ra một bài học xương máu: Làm việc với dữ liệu quan trọng mà không hiểu về Transaction và nguyên tắc ACID, thì sớm muộn gì cũng tự đào hố chôn mình.

Hôm nay, từ những "vết sẹo" đã trải qua, mình sẽ tóm lược lại khái niệm ACID theo cách thực dụng và dễ hiểu nhất để anh em tránh dẫm phải vết xe đổ nhé.

Trước hết, Transaction là gì?

Khoan bàn đến ACID, chúng ta cần hiểu Transaction (Giao dịch) là gì đã. Tưởng tượng Transaction như một gói các thao tác phải được thực hiện cùng nhau. Lấy ví dụ kinh điển nhất là chuyển 1 triệu từ tài khoản A sang tài khoản B. Quá trình này có 2 bước chính:

Trừ 1 triệu từ tài khoản A.
Cộng 1 triệu vào tài khoản B.

Nếu bước 1 thành công mà bước 2 lỗi (do sập server, rớt mạng...), tiền sẽ bốc hơi. Để giải quyết chuyện này, Database gom 2 bước trên vào một Transaction. Hệ quản trị cơ sở dữ liệu (DBMS) cam kết rằng: "Giao dịch này tuân thủ các nguyên tắc ACID".

Vậy ACID là viết tắt của cái gì? Cùng mổ xẻ nhé!

1. A - Atomicity (Tính toàn vẹn / "Được ăn cả, ngã về không")

Chữ A này có nghĩa là tất cả các thao tác trong một Transaction phải thành công trọn vẹn, hoặc nếu có một thao tác thất bại, toàn bộ quá trình sẽ bị hủy bỏ (Rollback) và dữ liệu trở về trạng thái y hệt như lúc chưa bắt đầu.

Kinh nghiệm thực chiến: Đừng bao giờ viết code trừ tiền và cộng tiền ở hai hàm rời rạc không bọc chung một transaction. Nếu server crash giữa chừng, hệ thống của bạn sẽ sinh ra dữ liệu rác (inconsistent data) cực kỳ khó fix bằng tay.

2. C - Consistency (Tính nhất quán / "Luật là luật")

Tính nhất quán đảm bảo rằng dữ liệu của bạn trước và sau khi thực hiện Transaction luôn phải hợp lệ, không vi phạm các quy tắc ràng buộc (constraints, triggers, cascades) đã định nghĩa trong DB.

Ví dụ: Bạn đặt luật (constraint) trong DB là số dư tài khoản balance >= 0. Nếu tài khoản A chỉ có 500k mà cố tình thực hiện Transaction chuyển 1 triệu, DB sẽ bắn ra lỗi ngay lập tức và Transaction bị hủy.
Kinh nghiệm thực chiến: Đừng chỉ bắt lỗi validation ở tầng Application (Code), hãy thiết lập các constraint chặt chẽ ở cả tầng DB. Code có thể có bug cho qua dữ liệu sai, nhưng Database thì không biết nói dối.

3. I - Isolation (Tính độc lập / "Việc ai nấy làm"

Đây là phần phức tạp nhất và là nơi sinh ra nhiều bug "ảo ma" nhất khi hệ thống có hàng ngàn user truy cập cùng lúc (Concurrency).

Isolation đảm bảo rằng nhiều Transaction chạy song song sẽ không được phép nhìn thấy hay can thiệp vào "dữ liệu đang làm dở" của nhau. Tùy thuộc vào Isolation Level bạn chọn (Read Uncommitted, Read Committed, Repeatable Read, Serializable), Database sẽ có cách khóa (lock) dữ liệu khác nhau.

Kinh nghiệm thực chiến: Nếu để Isolation level quá lỏng lẻo, bạn sẽ dính các lỗi như Dirty Read (đọc dữ liệu chưa commit) hay Phantom Read. Nhưng nếu để quá chặt (Serializable), hệ thống sẽ bị Lock, gây ra Deadlock hoặc chạy chậm như rùa bò. Hiểu và chọn đúng Isolation Level là một nghệ thuật tối ưu hiệu năng.

4. D - Durability (Tính bền vững / "Đã chốt là vĩnh viễn")

Khi một Transaction báo thành công (Committed), dữ liệu đó phải được lưu lại vĩnh viễn và an toàn trong ổ cứng. Ngay cả khi vừa báo commit xong thì server bị cúp điện, hoặc ổ cứng bị rút ra, lúc khởi động lại dữ liệu đó vẫn phải còn nguyên vẹn.

Kinh nghiệm thực chiến: Tính năng này được các DB Relational (như MySQL, PostgreSQL) đảm bảo bằng cách ghi log (như WAL - Write-Ahead Logging) trước khi thực sự ghi vào data file. Tuy nhiên, nó đổi lại bằng chi phí I/O (ghi ổ đĩa) khá tốn kém.

Đúc kết kinh nghiệm

Hiểu lý thuyết là một chuyện, nhưng áp dụng vào thực tế lại là một câu chuyện khác. Dưới đây là vài take-away dành cho anh em:

Không lạm dụng Transaction: Chỉ gom những query thực sự có liên quan mật thiết vào một Transaction. Bọc một khối code quá bự (gọi API ngoài, gửi email...) bên trong một Transaction là một tội ác. Nó sẽ hold lock DB của bạn và gây nghẽn toàn hệ thống.
NoSQL có ACID không? Ngày xưa thì NoSQL (như MongoDB) thường bỏ qua ACID để đổi lấy tốc độ và khả năng scale. Nhưng hiện nay, các bản MongoDB mới cũng đã hỗ trợ multi-document ACID transactions. Tuy nhiên, nếu nghiệp vụ của bạn đặt nặng tính ACID (như ngân hàng, kế toán), RDBMS (PostgreSQL, MySQL) vẫn là chân ái.

Hi vọng bài viết nhỏ này giúp anh em có cái nhìn rõ ràng hơn về ACID và không phải thức đêm mò bug data như mình ngày xưa. Cảm ơn anh em đã đọc! Happy Coding! 💻🚀