Bài 9: CAP & Các Mô Hình Nhất Quán

Bài 7 mục 7.4 để ngỏ một câu hỏi: khi mạng bị chia, không node nào biết bên kia đã chết hay chỉ mất liên lạc — hai tình huống đó giống nhau hoàn toàn từ bên trong. Bài này hình thức hoá câu hỏi đó, và quan trọng hơn, chỉ ra phần mà CAP bỏ sót nhưng bạn gặp hằng ngày.

Lab của bài này tạo partition thật bằng docker network disconnect, và câu trả lời hoá ra không phải "lỗi" hay "dữ liệu cũ" mà là cả ba thứ khác nhau trong ba lần gọi liên tiếp: request đầu treo 30 giây, hai request sau lỗi trong 29–40 ms, còn lệnh ghi vào primary vẫn thành công bình thường. Mô hình nhất quán mà bạn tưởng mình có và thứ hệ thống thật sự làm khi mạng đứt thường là hai chuyện khác nhau.

9.1 Đọc CAP cho đúng: P không phải là một lựa chọn

CAP thường được kể như "chọn hai trong ba: Consistency, Availability, Partition tolerance". Cách kể đó dẫn tới một kết luận sai ngay từ đầu, vì P không phải thứ bạn chọn. Mạng sẽ bị chia: cáp bị cắt, switch chết, một vùng mất kết nối, hoặc chỉ đơn giản là một container rời khỏi network. Đó là thực tế vật lý, không phải mục trong bảng cấu hình.

Phát biểu đúng: khi partition đang xảy ra, bạn phải chọn giữa C và A. Ngoài lúc đó, câu hỏi không tồn tại. Vì vậy khái niệm "hệ CA" là một nhầm lẫn — nó chỉ có nghĩa là "hệ chưa từng gặp partition", tức là một hệ chưa chạy đủ lâu.

Lab: partition thật, và ba hành vi khác nhau

Lý thuyết nói "chọn C hoặc A". Nhưng khi partition xảy ra thật, hệ thống của bạn làm gì? Câu trả lời thường không phải điều bạn nghĩ. Tách replica khỏi mạng trong lúc app đang đọc từ nó:

cd blog/sysdesign/sysdesign-lab
docker compose --profile replica up -d
NET=sysdesign-lab_default

# 1) Normal: reading from the replica works
curl -s "http://localhost:3001/rww?id=7"
# {"wroteVersion":1,"readVersion":1,"readFrom":"replica","stale":false}

# 2) CUT the replica off the network — a REAL partition at the network layer
docker network disconnect $NET sysdesign-lab-postgres-replica-1

# 3) What does the app do?
curl -s -m 30 "http://localhost:3001/rww?id=7"   # HANGS 30 SECONDS, client gives up
curl -s -m 30 "http://localhost:3001/rww?id=7"   # 40ms: ENOTFOUND postgres-replica
curl -s -m 30 "http://localhost:3001/rww?id=7"   # 29ms: ENOTFOUND postgres-replica

# 4) But what about WRITES to the primary? The primary was not cut off.
docker compose exec -T postgres psql -U lab -d lab -tAc \
  "UPDATE profiles SET version=version+1 WHERE id=7 RETURNING version;"
# 6 · UPDATE 1 · took 135ms — STILL SUCCEEDS

# 5) Reconnect. --alias is MANDATORY, otherwise DNS never comes back.
docker network connect --alias postgres-replica $NET sysdesign-lab-postgres-replica-1
curl -s "http://localhost:3001/rww?id=7"   # {"readVersion":9,"stale":false}
curl -s "http://localhost:3001/rww?id=7"   # {"readVersion":9,"stale":true} — catching up

9.2 PACELC — phần CAP bỏ sót, và bạn gặp hằng ngày

CAP chỉ nói về lúc có partition. Nhưng partition là chuyện hiếm; còn lại 99,9% thời gian mạng hoàn toàn bình thường — và trong suốt thời gian đó vẫn có một đánh đổi, chỉ là CAP không nhắc tới. PACELC bổ sung đúng phần đó:

if (P) then (A or C) else (L or C) — nếu có partition thì chọn giữa khả dụng và nhất quán; còn lại (Else) thì chọn giữa độ trễ (Latency) và nhất quán.

Nửa sau là nửa bạn gặp mỗi ngày, và bạn đã gặp nó ở Bài 7 mà không gọi tên: đọc từ replica thì nhanh nhưng có thể cũ; đọc từ primary thì mới nhưng chậm hơn và tốn tài nguyên của primary. Đó chính là "L hay C" — mạng không hề bị chia, mọi node đều khoẻ, và bạn vẫn phải chọn.

9.3 Phổ các mô hình nhất quán

"Nhất quán" không phải một công tắc bật/tắt mà là một dải. Mỗi mức mạnh hơn loại bỏ được một dạng bất thường mà người dùng có thể cảm nhận — và giá của nó là độ trễ hoặc khả dụng.

9.4 Quorum: vì sao $R + W > N$

Với $N$ bản sao, ghi vào $W$ bản và đọc từ $R$ bản. Nếu $R + W > N$ thì theo nguyên lý ngăn kéo, tập $W$ node vừa ghi và tập $R$ node đang đọc buộc phải có ít nhất một node chung — và node chung đó giữ bản mới nhất. Đó là toàn bộ ý tưởng.

Read-repair làm gì — và không làm gì

Read-repair là cơ chế: khi một lệnh đọc thấy trong tập $R$ có node giữ bản cũ, nó ghi bản mới sang node đó luôn. Điều thú vị là nó không làm giảm tỉ lệ đọc ra bản cũ của chính lần đọc đó — nó làm sự phân kỳ hội tụ.

Ghi một lần vào $W=1$ node, rồi đọc liên tiếp 40 lần với $R=2$, $N=3$ (20.000 lần thử):

Hai hàng bắt đầu giống nhau — 33,7% — và đó là điểm chính: read-repair không giúp gì cho lần đọc đầu tiên. Nhưng không có nó, tỉ lệ đứng nguyên ở 33% mãi mãi. Đó chính là nghĩa cụ thể của việc một hệ thống "eventual consistency" mà không bao giờ eventual: nếu không có cơ chế nào lan truyền bản mới sang các node lạc hậu, chúng cũ vĩnh viễn.

9.5 Linearizability, serializability, và cách LWW mất dữ liệu

Hai từ này hay bị dùng lẫn nhưng nói về hai chuyện khác nhau, và biết khác biệt giúp bạn hỏi đúng câu khi đọc tài liệu của một database:

Hệ quả thực tế: một database có thể serializable mà không linearizable (transaction đúng nhưng bạn đọc từ replica cũ), và ngược lại. Khi tài liệu nói "chúng tôi hỗ trợ serializable", đó là một phát biểu về transaction, không phải lời hứa rằng lệnh đọc của bạn sẽ thấy dữ liệu mới nhất.

Last-write-wins: mất dữ liệu, không một tiếng động

Khi hai lệnh ghi cùng đến, phải có quy tắc chọn ai thắng. Quy tắc đơn giản nhất — và phổ biến nhất — là last-write-wins: bản có dấu thời gian lớn hơn thắng. Vấn đề: "sau" được quyết định bằng đồng hồ tường, mà đồng hồ hai máy không bao giờ khớp tuyệt đối.

Kịch bản: client A ghi lúc $t=1000$, client B ghi sau đó 50 ms ở $t=1050$. Nhưng đồng hồ của B lệch. Chạy thật:

Ngưỡng chính là khoảng cách thời gian giữa hai lệnh ghi: chỉ cần đồng hồ lệch 50 ms — bằng đúng khoảng cách giữa hai lệnh ghi — là lệnh ghi sau bị bỏ. Và nó bị bỏ âm thầm: cả hai client đều nhận phản hồi thành công, không có lỗi nào, không có log nào ghi lại rằng một giá trị đã bị ghi đè bởi một giá trị cũ hơn.

function lastWriteWins({ clockSkewMs }) {
  // The REAL moment (by an imaginary perfect clock), in ms.
  const realTimeA = 1000;
  const realTimeB = 1050; // B writes exactly 50 ms AFTER A

  // But each client stamps using ITS OWN clock.
  const stampA = realTimeA + 0;
  const stampB = realTimeB + clockSkewMs; // B's clock is skewed

  const writes = [
    { client: 'A', value: 'balance = 100', realTime: realTimeA, stamp: stampA },
    { client: 'B', value: 'balance = 150', realTime: realTimeB, stamp: stampB },
  ];

  // LWW: the version with the HIGHEST timestamp wins.
  const winner = writes.reduce((a, b) => (b.stamp > a.stamp ? b : a));
  // What causality actually requires: the write that happened LATER in real time wins.
  const shouldWin = writes.reduce((a, b) => (b.realTime > a.realTime ? b : a));

  return {
    clockSkewMs,
    stampA,
    stampB,
    lwwWinner: winner.client,
    correctWinner: shouldWin.client,
    lostWrite: winner.client !== shouldWin.client,
    lostValue: winner.client !== shouldWin.client ? shouldWin.value : null,
  };
}

Còn một điều nữa mà bảng trên ngầm chỉ ra: mọi thứ ở đây phụ thuộc vào việc đồng hồ lệch bao nhiêu — một đại lượng bạn không kiểm soát và thường không đo. Bài 10 đi tiếp đúng theo mạch đó: một distributed lock cũng dựa trên giả định về thời gian, và khi giả định đó sai thì hai worker cùng tin mình đang giữ lock — dù Redis hoạt động hoàn toàn đúng.

Tự làm lại các phép đo

# Sections 9.4 and 9.5 — no Docker needed, runs in a few seconds
cd blog/sysdesign
node sysdesign-quorum.js

# Section 9.1 — a REAL partition between the app and the replica
cd sysdesign-lab
docker compose --profile replica up -d
NET=sysdesign-lab_default

curl -s "http://localhost:3001/rww?id=7"                         # normal
docker network disconnect $NET sysdesign-lab-postgres-replica-1  # CUT THE NETWORK

time curl -s -m 30 "http://localhost:3001/rww?id=7"  # hangs 30s — NO timeout in the app
curl -s -m 30 "http://localhost:3001/rww?id=7"       # ENOTFOUND in ~40ms

docker compose exec -T postgres psql -U lab -d lab -tAc \
  "UPDATE profiles SET version=version+1 WHERE id=7 RETURNING version;"   # WRITE still OK

# --alias is MANDATORY: without it DNS never comes back and the lab stays broken
docker network connect --alias postgres-replica $NET sysdesign-lab-postgres-replica-1
curl -s "http://localhost:3001/rww?id=7"

Tóm lại

P không phải lựa chọn — mạng sẽ bị chia. Lựa chọn giữa C và A chỉ xuất hiện trong lúc partition, và nó là lựa chọn cho từng thao tác chứ không cho cả hệ thống. Phần bạn gặp hằng ngày là nửa sau của PACELC: khi mạng hoàn toàn bình thường, mỗi đường đọc vẫn phải chọn giữa độ trễ và độ mới — và nếu không chọn thì mặc định đã chọn độ trễ.

$R + W > N$ đảm bảo tập đọc và tập ghi giao nhau, đo được đúng 0 lần đọc ra bản cũ trên 100.000 vòng; nhưng $R + W = N$ vẫn cho 33%, nên bất đẳng thức phải nghiêm ngặt. Quorum cho bạn giao nhau, không cho linearizability — thứ đó cần một giao thức đồng thuận. Và read-repair không cải thiện lần đọc đầu tiên; nó là thứ biến 33% đứng-nguyên-mãi-mãi thành 33% → 11,2% → 0,3% → 0%.

Phát hiện đáng nhớ nhất của bài này đến từ lab: partition không xuất hiện dưới dạng lỗi mà dưới dạng im lặng — request đầu tiên treo 30 giây, không lỗi, không đóng kết nối. Nghĩa là nếu bạn không đặt timeout thì bạn đã chọn A một cách vô tình, và đó là lựa chọn tệ nhất trong ba: vừa không nhất quán, vừa không khả dụng.