Từ ACID single-node tới giao dịch phân tán

TL;DR: Transaction cho hai đảm bảo chính: atomicity (mọi thao tác cùng commit hoặc cùng huỷ, không nửa vời) và isolation (giao dịch đồng thời không giẫm chân nhau, như chạy tuần tự). Trên một node, một write-ahead log và một lock/MVCC manager lo cả hai. Khi giao dịch trải trên nhiều node, cả hai vỡ: atomicity cần mọi node đồng ý commit dù mạng có thể chết giữa chừng — sinh ra 2PC; isolation cần ngăn anomaly xuyên node mà không có lock manager trung tâm. Bài này ôn ACID và chỉ rõ điều gì vỡ khi lên nhiều node, đặt nền cho các bài sau.

Bạn đã thấy transaction "chạy đẹp" trên một database. Câu hỏi của module: khi tài khoản A ở node 1 và tài khoản B ở node 2, làm sao "trừ A, cộng B" vẫn hoặc-cả-hai-hoặc-không-cái-nào — khi node 2 có thể chết đúng lúc node 1 vừa trừ xong? Trước khi giải, phải hiểu rõ cái gì trở nên khó.

1. Analogy — hai két sắt ở hai thành phố

Trên một node, transaction như một két sắt có người gác: mọi thay đổi ghi vào sổ nháp, tới lúc "commit" thì đóng dấu một phát — hoặc xé bỏ toàn bộ nếu huỷ. Một người gác, một quyết định, không ai chen.

Giờ tiền của bạn nằm trong hai két ở hai thành phố (hai node), và bạn muốn chuyển từ két A sang két B. Không còn một người gác chung. Bạn nhắn hai nơi "trừ 100 ở A, cộng 100 ở B". Nếu A trừ xong mà B mất điện trước khi cộng — tiền bốc hơi. Nếu bạn bảo cả hai "chuẩn bị" rồi mới "chốt", nhưng người báo chốt lăn ra ngất giữa chừng — A không biết nên chốt hay huỷ, ngồi treo giữ tiền. Đây chính là hai cái khó: cùng quyết (atomicity) và không biết đối phương chết hay chậm.

2. Ôn nhanh — vì sao một node đủ để đảm bảo cả hai

Trên một node, cả atomicity (all-or-nothing) lẫn isolation (đồng thời như tuần tự) đứng được nhờ một điểm điều phối trung tâm: một write-ahead log lo atomicity (ghi ý định trước; commit = đóng một dấu "committed"; crash trước dấu đó thì lúc khởi động lại rollback phần dở), và một lock/MVCC manager duy nhất lo isolation (điều phối khoá hoặc ảnh chụp nhất quán cho mọi giao dịch).

Single-node transaction (chuyen tien trong 1 DB):
  BEGIN
    UPDATE acc SET bal = bal - 100 WHERE id = A   -- ghi WAL
    UPDATE acc SET bal = bal + 100 WHERE id = B   -- ghi WAL
  COMMIT                                           -- 1 dau "committed" -> atomic
  => WAL + lock manager cua CUNG mot node lo atomicity + isolation.

Mấu chốt mang sang phần sau: cả hai đảm bảo cùng dựa vào MỘT thứ đó. Distributed transaction khó chính vì thứ đó không còn tồn tại một cách tự nhiên khi dữ liệu trải nhiều node — và phần dưới sẽ lần theo đúng cơ chế WAL để thấy nó vỡ ở đâu.

3. Điều gì vỡ khi lên nhiều node?

Đặt hai tài khoản ở hai node và thử "gọi hai update trong một khối code" như thể vẫn là một giao dịch. Trước khi xem nó vỡ ở đâu, hãy tự lần theo cơ chế WAL vừa ôn.

Chuyen tien A (node 1) -> B (node 2), goi hai update trong 1 khoi code:

t0  Node1: BEGIN; A -= 100; ghi WAL rieng
t1  Node1: COMMIT -> WAL node1 dong dau "committed"
        -> A giam 100 that su, da BEN (durable)
t2  Node2: BEGIN; B += 100; ghi WAL rieng (chua commit)
t3  Node2: CHET (mat dien) TRUOC khi COMMIT
t4  Node2 song lai: WAL node2 KHONG co dau "committed"
        -> rollback phan do cua RIENG no -> B khong doi

Ket qua: A: -100 (da tru, ben) | B: +0 (khong cong)
        -> mot NUA giao dich da hieu luc -> mat 100, vi pham "tong khong doi"

Lần theo cơ chế: ở t4, WAL của node 2 làm đúng việc của nó — thấy không có dấu "committed" nên rollback phần dở của chính node 2. Nhưng đó là phục hồi cục bộ. Không có một WAL chung hay một lock manager chung nào bắc qua cả hai node để thấy bức tranh "node 1 đã commit, node 2 fail → phải cuộn lại node 1". Còn node 1, từ góc nhìn của nó, giao dịch đã thành công và bền — nó không có lý do gì tự revert. Không ai giữ bức tranh toàn cục để kích hoạt rollback — chính là "điểm điều phối trung tâm" đã biến mất. Đây là cơ chế gốc của mọi thứ còn lại trong module: để cuộn lại được, các node phải thoả thuận trước khi bất kỳ ai commit (2PC, bài 03), hoặc bù trừ sau khi đã commit (saga, bài 04).

flowchart TB
  T["Chuyen tien A -> B (2 node)"] --> N1["Node 1: A -= 100<br/>WAL rieng -> COMMIT ok (ben)"]
  T --> N2["Node 2: B += 100<br/>CHET truoc commit -> rollback cuc bo"]
  N1 --> R["A mat 100, B khong nhan<br/>-> khong WAL chung de cuon lai node 1"]
  N2 --> R

Từ mini-trace đó, hai đảm bảo vỡ theo hai hướng:

Atomicity vỡ vì mỗi node commit độc lập. Node 1 có WAL của nó, node 2 có WAL của nó. Node 1 có thể commit thành công trong khi node 2 fail — và không có "một dấu committed chung" để cả hai cùng nhìn. Cần một nghi thức để mọi node đồng ý cùng commit hoặc cùng abort, chịu được việc một node/mạng chết giữa chừng. Đó là two-phase commit (bài 03) — và nó phải cử một coordinator đóng vai "người báo chốt", kéo theo điểm yếu blocking.

Isolation vỡ vì không có lock manager chung. Hai giao dịch đụng dữ liệu ở các node khác nhau; không manager đơn lẻ nào thấy toàn cảnh để ngăn chúng giẫm chân. Bài 02 ôn lại các anomaly (lost update, write skew) ở mức single-node làm nền — vì khi phân tán, đảm bảo "serializable" (như thể tuần tự) còn khó hơn nhiều, và đó không phải thứ 2PC (bài 03) giải được (2PC chỉ lo atomicity, không lo isolation xuyên node).

4. Pitfall — bê nguyên tư duy single-node transaction lên nhiều node

❌ Chuyen tien: node1.trUpdate(A -= 100); node2.trUpdate(B += 100);
   xem nhu "atomic" vi co goi trong 1 khoi code
   -> node1 commit xong, node2 mat mang -> A mat 100, B khong nhan -> tien bay
   -> khong co WAL chung -> khong co all-or-nothing that su

❌ Tuong isolation tu dong dung xuyen service vi "moi service co transaction"
   -> hai giao dich o hai node van co the tao anomaly (bai 02)

5. 📚 Deep Dive

6. Liên hệ các bài khác

• Bài 02 — Anomaly & serializability: đào sâu phần isolation — các anomaly cụ thể và chuẩn serializable.
• Bài 03 — 2PC: cơ chế cho atomicity xuyên node — và vì sao coordinator làm nó blocking.
• Module 2 — Replication: dữ liệu trải nhiều node (do replication + partitioning) là lý do transaction phải xuyên node.
• Module 6 — CAP đúng nghĩa: ba chữ "consistency" (ACID-C, CAP-C, replication) khác nghĩa — sẽ tách bạch ở đó.

7. Tóm tắt

• Transaction = atomicity (cùng commit/cùng huỷ) + isolation (đồng thời như tuần tự); trên một node do WAL + lock/MVCC của cùng một node lo.
• Cả hai dựa vào một điểm điều phối trung tâm — thứ biến mất khi dữ liệu trải nhiều node.
• Atomicity xuyên node: mỗi node commit độc lập → cần nghi thức "cùng quyết" chịu lỗi giữa chừng → 2PC (bài 03).
• Isolation xuyên node: không có lock manager chung → anomaly xuyên node, serializable khó hơn (bài 02).
• Consistency (chữ C) là trách nhiệm ứng dụng; database cấp atomicity + isolation làm công cụ.
• Anti-pattern: bê nguyên "BEGIN...COMMIT là atomic" lên nhiều node → mất tính atomic im lặng.

8. Tự kiểm tra

Bài tiếp theo: Anomaly & serializability — lost update, write skew, SSI