ACID deep dive — Atomicity, Consistency, Isolation, Durability thực sự là gì

AI cũng nói ACID. Mọi tutorial đều có slide "Atomicity = all-or-nothing, Consistency = data luôn đúng, Isolation = các tx không ảnh hưởng nhau, Durability = ghi vào disk". Nghe quen. Nhưng khi phỏng vấn hỏi "Consistency trong ACID nghĩa là gì chính xác?" — đa số trả lời sai. Nhiều kỹ sư nghĩ ACID đảm bảo toàn bộ business logic đúng, rồi bị bất ngờ khi bug tiền vẫn xuất hiện dù database dùng transaction.

Thực tế, mỗi chữ trong ACID có một định nghĩa hẹp và cụ thể hơn rất nhiều so với cách thường được giải thích. Bài này mở từng chữ ra, xem cơ chế implement thực sự là gì, và chỉ ra đúng nơi ACID bảo vệ — cũng như đúng nơi bạn vẫn phải tự lo.

1. Analogy — ATM rút tiền

Hãy dùng ATM như metaphor sống: bạn bước đến máy, nhét thẻ, nhập số tiền, máy trừ tài khoản và nhả tiền mặt. Bốn bước, bốn câu hỏi ACID:

2. Atomicity — không phải magic, là undo log và commit record

"All-or-nothing" nghe như phép thuật. Thực tế implement qua hai cơ chế:

Write-Ahead Log (WAL): Trước khi bất kỳ thay đổi nào được ghi xuống data page, PostgreSQL ghi một bản ghi WAL mô tả thay đổi đó — "TX 12345: UPDATE accounts SET balance = 900 WHERE id = 1 (truoc: 1000)". WAL flush trước, data page flush sau. Thứ tự này là bất biến.

Crash recovery: Khi server khởi động lại sau crash, PG đọc WAL từ checkpoint gần nhất:

• WAL record có "TX 12345 COMMITTED" → redo thay đổi đó vào data page.
• WAL record không có "COMMITTED" → transaction chưa commit khi crash → bỏ qua (với MVCC, các tuple chưa commit bị bỏ qua tự nhiên vì xmin của chúng chưa được đánh dấu committed trong pg_xact).

Commit record: Dòng WAL "TX 12345 COMMITTED" là ranh giới. Flush dòng này xuống disk = transaction durable và committed. Chưa flush = chưa commit, dù đã sửa bao nhiêu data page trong bộ nhớ.

-- Anatomy cua mot atomic transfer
BEGIN;
  UPDATE accounts SET balance = balance - 100 WHERE id = 1;
  -- WAL ghi: "TX 100: accounts.id=1 balance 1000->900"
  UPDATE accounts SET balance = balance + 100 WHERE id = 2;
  -- WAL ghi: "TX 100: accounts.id=2 balance 500->600"
COMMIT;
  -- WAL ghi: "TX 100 COMMITTED" -> flush -> return client
  -- Chi sau dong nay moi la committed

Nếu crash xảy ra trước dòng COMMITTED: PG restart thấy TX 100 không có commit record → coi như chưa tồn tại. Hai UPDATE kia không bao giờ được apply vào data page (hoặc nếu đã apply vào buffer, bị discard vì tuple có xmin = 100 và TX 100 không được đánh dấu committed trong pg_xact).

3. Consistency — chỉ là constraint, không phải business logic

Đây là chữ bị hiểu sai nhiều nhất. Định nghĩa chính xác từ Jim Gray 1981: một transaction đưa database từ một consistent state sang một consistent state khác — nghĩa là không vi phạm bất kỳ integrity constraint nào database đang enforce.

Database enforce được:

-- NOT NULL: khong the insert task khong co title
INSERT INTO tasks(project_id, title, status)
VALUES (1, NULL, 'todo');
-- ERROR: null value in column "title" violates not-null constraint

-- CHECK constraint: balance phai >= 0
CREATE TABLE accounts (
  id      BIGSERIAL PRIMARY KEY,
  user_id BIGINT NOT NULL REFERENCES users(id),
  balance NUMERIC(15,2) NOT NULL CHECK (balance >= 0)
);
UPDATE accounts SET balance = -50 WHERE id = 1;
-- ERROR: new row violates check constraint "accounts_balance_check"

-- UNIQUE: email phai doc nhat
INSERT INTO users(email, name) VALUES ('[email protected]', 'Duplicate');
-- ERROR: duplicate key value violates unique constraint "users_email_key"

-- FOREIGN KEY: task phai thuoc project ton tai
INSERT INTO tasks(project_id, title, status) VALUES (99999, 'Orphan', 'todo');
-- ERROR: insert or update violates foreign key constraint

Database KHÔNG enforce được (dù bạn muốn):

• "Tổng debit = tổng credit trong mọi giao dịch kế toán" — đây là business invariant, không phải DB constraint. Database không biết luật kế toán tồn tại.
• "User không thể comment trên task thuộc project mà user không phải thành viên" — cần CHECK phức tạp hoặc trigger, không tự nhiên được enforce.
• "Số task đang làm (doing) trong một sprint không vượt quá 10" — không thể viết thành constraint đơn giản.

Những invariant này là trách nhiệm của application layer — validation logic, service layer, hoặc tầng domain model.

4. Isolation — tease, sẽ đi sâu ở bài 3 của module này

Database phải hành xử như mỗi transaction chạy một mình — dù thực tế có hàng chục transaction chạy đồng thời. Làm thế nào? Đây là câu hỏi phức tạp nhất trong ACID.

SQL chuẩn định nghĩa 4 isolation level (Read Uncommitted, Read Committed, Repeatable Read, Serializable) và 4 anomaly cần ngăn (dirty read, non-repeatable read, phantom read, serialization anomaly). PostgreSQL implement qua MVCC — mỗi transaction nhìn vào một snapshot nhất quán của data tại thời điểm transaction bắt đầu, không block lẫn nhau khi chỉ đọc.

Phần này sẽ được mở rộng đầy đủ ở bài 3 của module này (M06.3 — Isolation Levels và MVCC anomalies). Ở đây chỉ cần nhớ: Isolation KHÔNG có nghĩa là "các tx hoàn toàn không ảnh hưởng nhau" — mức độ cô lập phụ thuộc isolation level, và mỗi level có trade-off riêng về correctness vs throughput.

5. Durability — fsync WAL, không phải ghi disk magic

"Ghi vào disk" nghe đơn giản, nhưng OS có page cache — ghi xuống OS chưa chắc đã xuống disk vật lý. Server mất điện ngay sau đó, OS cache mất, data mất.

Durability PostgreSQL đảm bảo: sau khi COMMIT return về client, data không mất dù server crash ngay lập tức. Cơ chế:

1. COMMIT trigger flush WAL buffer → WAL file trên disk.
2. Flush thực hiện qua fsync() — gọi OS yêu cầu disk controller xác nhận data đã xuống persistent storage.
3. Chỉ sau khi fsync() return, COMMIT mới return về client.

Client                  PG process              WAL file (disk)
  |                         |                        |
  |--- COMMIT ------------->|                        |
  |                         |--- WAL flush --------->|
  |                         |<--- fsync() OK --------|
  |<--- COMMIT OK ----------|                        |
  |                         |                        |
  (neu crash o day: WAL da tren disk -> recovery OK)

Group commit: nếu 100 transaction commit gần nhau trong cùng một khoảng thời gian ngắn, PG có thể gộp tất cả WAL record của chúng vào một lần fsync() duy nhất. Thay vì 100 fsync() (tốn kém), chỉ cần 1 fsync() cho 100 tx. Throughput tăng đáng kể; latency mỗi tx tăng nhẹ (phải chờ window group commit).

synchronous_commit = off — async commit:

-- Thay doi cho session hien tai
SET synchronous_commit = off;

-- Hoac thay doi cho mot transaction cu the
BEGIN;
  INSERT INTO analytics_events(event_type, payload) VALUES ('page_view', '{}');
COMMIT; -- Return ngay, KHONG cho fsync WAL

Với synchronous_commit = off: COMMIT return về client ngay khi WAL ghi vào RAM buffer của PG — không chờ fsync(). Crash ngay sau COMMIT? WAL chưa xuống disk, transaction có thể mất. Đây là tradeoff durability vs throughput — chấp nhận được cho workload analytics (mất vài page view không sao) nhưng không được cho chuyển khoản ngân hàng.

6. Vì sao group commit và async commit là trade-off

PostgreSQL default là sync commit với group commit tự động khi tải cao — tradeoff hợp lý nhất cho OLTP. Async commit là opt-in, phải hiểu rõ trước khi bật.

7. Pitfall — ACID không thay thế app validation

8. Applied — TaskFlow chuyển khoản 2 account

Scenario: TaskFlow mở rộng sang feature "thanh toán milestone" — khi task hoàn thành, tiền từ tài khoản client chuyển sang tài khoản contractor. Đây là nơi Atomicity trở nên quan trọng nhất.

-- Demo schema phu them ngoai TaskFlow goc
-- (5 bang goc: users/projects/project_members/tasks/comments khong thay doi)
CREATE TABLE accounts (
  id      BIGSERIAL PRIMARY KEY,
  user_id BIGINT NOT NULL REFERENCES users(id),
  balance NUMERIC(15,2) NOT NULL CHECK (balance >= 0)
);

-- Seed du lieu test
INSERT INTO accounts(user_id, balance) VALUES
  (1, 1000.00),  -- client
  (2, 500.00);   -- contractor

-- Atomic transfer: tru tien client, cong tien contractor
BEGIN;

UPDATE accounts
  SET balance = balance - 100.00
  WHERE id = 1;
-- WAL ghi mutation nay

UPDATE accounts
  SET balance = balance + 100.00
  WHERE id = 2;
-- WAL ghi mutation nay

COMMIT;
-- WAL flush -> fsync -> return OK
-- Ca hai UPDATE hoac khong cai nao

Thử scenario thất bại — CHECK constraint bắt balance âm:

-- Client chi con 50, thu transfer 200
BEGIN;

UPDATE accounts SET balance = balance - 200.00 WHERE id = 1;
-- Lenh nay thanh cong (balance = -150 trong buffer)

UPDATE accounts SET balance = balance + 200.00 WHERE id = 2;
-- Cung thanh cong trong buffer

COMMIT;
-- CHECK (balance >= 0) duoc enforce khi ghi -> ROLLBACK toan bo
-- ERROR: new row for relation "accounts" violates check constraint
-- "accounts_balance_check"

Kết quả: cả hai UPDATE bị rollback — không trừ, không cộng. Atomicity giữ trạng thái nhất quán.

Lưu ý điều CHECK constraint KHÔNG làm: nếu hai transaction cùng đọc balance = 1000 và cùng trừ 800 — cả hai có thể pass CHECK (1000 - 800 = 200 ≥ 0) và commit thành công, kết quả balance = 200 thay vì phải là -600. Race condition này cần SELECT FOR UPDATE — xem bài 3 của module này.

-- Pattern dung cho concurrent transfer
BEGIN;

SELECT balance FROM accounts WHERE id = 1 FOR UPDATE;
-- Lock row id=1, transaction khac phai cho

UPDATE accounts SET balance = balance - 100.00 WHERE id = 1;
UPDATE accounts SET balance = balance + 100.00 WHERE id = 2;

COMMIT;

9. Deep Dive — Nguồn gốc và cơ chế ACID

10. Tóm tắt

• Atomicity = undo log + commit record (WAL): WAL ghi mọi mutation trước khi flush data page; crash recovery redo WAL committed, bỏ qua WAL uncommitted. Không phải magic.
• Consistency = constraint không bị vi phạm: DB enforce NOT NULL, CHECK, UNIQUE, FK — không hơn không kém. Business invariant là trách nhiệm của application.
• Isolation = snapshot, sẽ đi sâu ở bài 3 của module này: 4 isolation level, 4 anomaly. PG dùng MVCC — reader không block writer và ngược lại.
• Durability = fsync WAL trước khi COMMIT return: Không phải "ghi disk" chung chung — là fsync() xác nhận WAL đã ở persistent storage.
• Group commit tự động gộp nhiều tx vào 1 fsync: Throughput tốt hơn với latency tăng nhẹ — mặc định trong PG.
• synchronous_commit = off là opt-in trade-off: COMMIT return trước khi WAL xuống disk — có thể mất tx vừa commit nếu crash. Chỉ dùng cho data không quan trọng.
• ACID không thay thế app validation: Race condition (lost update), network failure + duplicate, và business invariant vẫn cần application xử lý.
• Bài tiếp theo: BEGIN, COMMIT, SAVEPOINT — kiểm soát transaction lifecycle

11. Tự kiểm tra

Bài tiếp theo: BEGIN, COMMIT, SAVEPOINT — kiểm soát transaction lifecycle