Thảo luận về ACID trong Databases

Posted on Updated on

ACID là gì?

Hãy tưởng tượng bạn đang vận hành một ứng dụng thương mại điện tử. Khi khách đặt hàng, hệ thống phải đồng thời trừ sản phẩm trong kho, thu tiền qua thẻ tín dụng và ghi nhận doanh thu trong sổ sách kế toán. Nếu thẻ thanh toán bị từ chối trong khi kho đã bị trừ, hoặc ứng dụng đột ngột “chết” giữa chừng, điều gì sẽ xảy ra? Những tình huống như vậy đòi hỏi cơ chế transaction đảm bảo mọi bước trong quá trình diễn ra một cách đáng tin cậy.

ACID là chữ viết tắt của bốn tính chất xác định nên một transaction đúng nghĩa: Atomicity (tính nguyên tử), Consistency (tính nhất quán), Isolation (tính cô lập) và Durability (tính bền vững). Những tính chất này giúp đảm bảo các hoạt động quan trọng diễn ra trọn vẹn, không để lại trạng thái trung gian gây lỗi.

Database transaction là gì?

Trong cơ sở dữ liệu, một transaction là chuỗi một hoặc nhiều thao tác (chèn, cập nhật, xoá…) được coi như một hành động duy nhất. transaction hoặc hoàn thành toàn bộ, hoặc hủy bỏ toàn bộ – không có trạng thái “dở dang”. Lấy ví dụ chuyển tiền: khi bạn gửi tiền cho bạn bè, vừa có thao tác trừ tiền khỏi tài khoản của bạn, vừa có thao tác cộng tiền vào tài khoản người nhận. Hai bước này tạo thành một transaction; nếu bước nào thất bại, cả hai đều bị huỷ. Không có transaction, dữ liệu dễ rơi vào trạng thái không nhất quán như trừ tiền nhưng người nhận không nhận được.

1. Atomicity – Tính nguyên tử

Tính nguyên tử bảo đảm transaction bao gồm nhiều thao tác phải diễn ra như một đơn vị không thể tách rời: hoặc hoàn thành toàn bộ, hoặc thất bại toàn bộ. Nếu bất kỳ phần nào thất bại, toàn bộ transaction sẽ được khôi phục lại trạng thái trước khi bắt đầu. Ví dụ, trong transaction chuyển tiền, nếu bước ghi có (credit) thất bại, bước ghi nợ (debit) cũng bị vô hiệu để tránh việc “tiền biến mất” khỏi một tài khoản mà không xuất hiện ở tài khoản khác. Điều này giúp lập trình viên không phải tự xử lý việc “undo” các thay đổi.

Cơ chế thực thi

  • Write‑Ahead Log (WAL): mỗi thao tác được ghi vào nhật ký trước khi áp dụng lên bảng dữ liệu. Nếu xảy ra lỗi, cơ sở dữ liệu dùng nhật ký này để hoàn tác các thay đổi dang dở.
  • Lệnh COMMIT / ROLLBACK: cơ sở dữ liệu cung cấp các lệnh như BEGIN TRANSACTION, COMMIT và ROLLBACK. Mọi thay đổi giữa BEGIN và COMMIT chỉ được áp dụng vĩnh viễn khi COMMIT thành công; nếu thất bại hoặc gọi ROLLBACK, toàn bộ thay đổi đều bị huỷ.

2. Consistency – Tính nhất quán

Tính nhất quán đảm bảo bất kỳ transaction nào cũng đưa cơ sở dữ liệu từ một trạng thái hợp lệ sang một trạng thái hợp lệ khác, không bao giờ rơi vào trạng thái “sai”. Điều này có nghĩa là mọi ràng buộc toàn vẹn dữ liệu – khóa chính (không trùng lặp ID), khóa ngoại (bản ghi liên quan phải tồn tại), ràng buộc kiểm tra (ví dụ, tuổi không thể âm) – đều được thoả mãn trước và sau transaction. Nếu một transaction vi phạm các ràng buộc này, nó sẽ không được chấp nhận và cơ sở dữ liệu sẽ trở về trạng thái trước đó.

Ví dụ

Giả sử bạn có hai bảng trong hệ thống thương mại điện tử: products và orders. Ràng buộc: không thể đặt hàng với số lượng lớn hơn số hàng còn trong kho. Nếu người dùng cố đặt 10 sản phẩm khi kho chỉ còn 8, cơ sở dữ liệu nhận thấy số tồn kho mới sẽ là -2, vi phạm ràng buộc, nên transaction sẽ bị hủy.

Cách áp dụng tính nhất quán

  1. Ràng buộc trên lược đồ (schema): NOT NULL, UNIQUE, PRIMARY KEY, FOREIGN KEY, CHECK và các định nghĩa khác ngăn dữ liệu không hợp lệ.
  2. Trigger và Stored Procedure: trigger tự động kiểm tra quy tắc mỗi khi bản ghi được chèn, cập nhật hoặc xóa; stored procedure chứa logic kiểm tra dữ liệu trước khi commit.
  3. Kiểm tra ở tầng ứng dụng: ngoài cơ sở dữ liệu, ứng dụng thường bổ sung các kiểm tra để đảm bảo quy tắc nghiệp vụ trước khi gửi dữ liệu xuống DB.

3. Isolation – Tính cô lập

Tính cô lập đảm bảo rằng các transaction chạy đồng thời không can thiệp vào trạng thái trung gian của nhau. Khi một transaction đang thực thi, các thay đổi tạm thời của nó không thể được các transaction khác nhìn thấy, như thể mọi transaction chạy tuần tự từng cái một. Nếu không có tính cô lập, các transaction có thể đọc hoặc ghi dữ liệu chưa được commit của nhau, dẫn đến kết quả sai lệch.

Các hiện tượng cạnh tranh phổ biến

  1. Dirty Read: transaction A đọc dữ liệu mà transaction B đã sửa nhưng chưa commit; nếu B rollback, A giữ giá trị “bẩn” chưa từng tồn tại.
  2. Non‑Repeatable Read: transaction A đọc cùng một dòng nhiều lần nhưng thấy dữ liệu khác nhau vì transaction khác đã cập nhật hoặc xóa các dòng đó giữa các lần đọc.
  3. Phantom Read: transaction A thực thi một truy vấn trả về một tập hợp dòng; transaction khác thêm/xoá/cập nhật các dòng phù hợp. Khi A lặp lại truy vấn, nó thấy một tập hợp dòng khác (“bóng ma”).

Các mức độ cô lập

Cơ sở dữ liệu thường cho phép bạn chọn mức cô lập, cân bằng giữa độ đúng và hiệu năng:

  1. Read Uncommitted – cho phép dirty read, hiếm khi dùng vì dễ gây lỗi.
  2. Read Committed – chỉ đọc dữ liệu đã được commit, ngăn dirty read nhưng vẫn có non‑repeatable read và phantom read.
  3. Repeatable Read – đảm bảo đọc nhiều lần cùng một dòng luôn cho kết quả giống nhau; ngăn dirty read và non‑repeatable read, nhưng phantom read vẫn có thể xảy ra tùy vào hệ quản trị.
  4. Serializable – mức cao nhất, xử lý như thể các transaction chạy tuần tự; ngăn mọi loại bất thường nhưng tốn kém hiệu năng do cần nhiều khóa hoặc kiểm tra xung đột.

Cơ chế thực thi

  • Khoá (Pessimistic Concurrency Control): khóa hàng hoặc bảng để transaction khác không thể đọc/ghi cho đến khi khóa được giải phóng, dễ gây “deadlock”.
  • MVCC (Multi‑Version Concurrency Control): tạo nhiều phiên bản của một hàng; người đọc thấy ảnh chụp dữ liệu tại một thời điểm, người ghi tạo bản phiên bản mới. Cách này giảm tranh chấp khóa nhưng cần dọn dẹp các phiên bản cũ.
  • Snapshot Isolation: một hình thức MVCC; mỗi transaction thấy dữ liệu ở thời điểm bắt đầu (snapshot). Nó ngăn non‑repeatable read và dirty read, nhưng phantom read có thể xảy ra nếu mức serializable không được áp dụng.

4. Durability – Tính bền vững

Tính bền vững đảm bảo rằng một khi transaction đã commit, các thay đổi của nó sẽ tồn tại ngay cả khi xảy ra mất điện, sự cố hệ thống hay thiên tai. Nói cách khác, khi transaction báo “xong”, dữ liệu được ghi vĩnh viễn và không thể biến mất một cách tự nhiên.

Cách đảm bảo tính bền vững

  1. Nhật ký (Write‑Ahead Logging): hầu hết cơ sở dữ liệu quan hệ sử dụng WAL, ghi các thay đổi vào nhật ký bền vững trước khi ghi vào file dữ liệu chính. Khi commit, cơ sở dữ liệu lưu trạng thái vào nhật ký; nếu hệ thống gặp sự cố, nó dùng nhật ký để làm lại (redo) các transaction đã commit chưa cập nhật vào file chính và hoàn tác (undo) các transaction chưa hoàn tất.
  2. Nhân bản (Replication): nhiều hệ thống nhân bản dữ liệu sang node hoặc trung tâm dữ liệu khác. Replication đồng bộ chỉ báo commit khi cả node chính và node phụ đều lưu trữ an toàn. Replication bất đồng bộ có thể trễ; nếu node chính hỏng trước khi đồng bộ xong, có nguy cơ mất dữ liệu.
  3. Sao lưu (Backup): sao lưu định kỳ tạo lưới an toàn bổ sung. Sao lưu toàn phần lưu toàn bộ cơ sở dữ liệu tại thời điểm cụ thể; sao lưu tăng dần hoặc vi sai lưu các thay đổi kể từ lần sao lưu trước để tiết kiệm thời gian và dung lượng. Lưu trữ sao lưu ở vị trí khác giúp bảo vệ khỏi thảm hoạ tại chỗ.

Kết luận

Transaction trong cơ sở dữ liệu giúp xử lý các thao tác quan trọng như chuyển tiền, đặt hàng… một cách an toàn. Bộ tính chất ACID – Tính nguyên tử, Nhất quán, Cô lập và Bền vững – tạo ra nền tảng để đảm bảo dữ liệu luôn chính xác và đáng tin cậy trong mọi tình huống. Hiểu và áp dụng đúng ACID giúp nhà phát triển và kiến trúc sư dữ liệu xây dựng hệ thống vững chắc, tránh sai sót, đồng thời tối ưu hiệu năng và khả năng mở rộng.