CAP đúng nghĩa — P bắt buộc, chọn C hay A

TL;DR: Định lý CAP hay bị đọc sai thành "chọn 2 trong 3". Cách đọc đúng: Partition (P) không phải một lựa chọn — mạng SẼ phân mảnh, nên P luôn phải chịu. Khi partition đang xảy ra, mỗi node bị cắt phải chọn giữa C (linearizability — từ chối phục vụ để không trả lời sai) và A (vẫn trả lời nhưng có thể trả dữ liệu cũ). Ngoài lúc partition, một hệ có thể có cả C lẫn A. Phân loại thực dụng: CP (hy sinh khả dụng khi partition) vs AP (hy sinh nhất quán khi partition). "C" trong CAP nghĩa hẹp là linearizability — mức yếu hơn (causal) vẫn khả dụng khi partition, nằm ngoài đánh đổi gắt này.

"Hệ của mình chọn CA — nhất quán và khả dụng, khỏi lo partition." Câu này nghe hợp lý nhưng sai về bản chất: trong một hệ phân tán thật, mạng sẽ rớt gói, đứt cáp, nghẽn — partition không phải rủi ro bạn chọn gánh hay không, nó là điều kiện tự nhiên. Không thể "bỏ P" như bỏ một topping. Hiểu lầm "2 trong 3" khiến vô số kiến trúc chọn sai và ngạc nhiên khi hệ vừa treo vừa sai lúc mạng có sự cố.

Bài này sửa lại cách đọc CAP cho đúng định lý gốc (Gilbert & Lynch, 2002), làm rõ vì sao P bắt buộc, vì sao đánh đổi thật chỉ hiện ra khi partition, và vì sao "C" ở đây hẹp hơn "nhất quán" nói chung.

1. Analogy — hai chi nhánh ngân hàng mất liên lạc

Một ngân hàng có hai chi nhánh dùng chung sổ số dư, nối nhau bằng một đường truyền. Bình thường mọi giao dịch đồng bộ tức thì. Rồi đường truyền đứt (partition): chi nhánh A không còn nói chuyện được với B. Một khách tới A rút tiền. A đứng trước đúng hai lựa chọn:

• Giữ nhất quán (C): "Xin lỗi, hiện chưa xác nhận được số dư mới nhất bên B, tôi không phục vụ để tránh cho rút quá tay." → đúng nhưng từ chối khách (mất availability).
• Giữ khả dụng (A): "Cứ cho rút theo số dư tôi đang có." → phục vụ được, nhưng nếu B cũng vừa cho rút thì tổng có thể âm — dữ liệu không nhất quán.

Không có cửa thứ ba khi đường đã đứt. Và không thể "chọn không đứt cáp" — đứt cáp là sự cố tự nhiên, không phải tuỳ chọn. Đó là toàn bộ tinh thần CAP.

2. Định nghĩa chính xác — CAP của Gilbert & Lynch (2002)

Ba chữ trong phát biểu hình thức (Gilbert & Lynch, 2002 — chứng minh chặt phỏng đoán của Brewer):

• C — Consistency: ở đây nghĩa hẹp là linearizability (bài 01) — mọi thao tác thấy một sự thật mới nhất duy nhất. Không phải chữ C trong ACID.
• A — Availability: mọi request tới một node không lỗi đều nhận được một phản hồi (không treo vô hạn). Lưu ý: không đòi phản hồi nhanh, chỉ đòi có phản hồi.
• P — Partition tolerance: hệ vẫn tiếp tục hoạt động dù mạng làm rớt/hoãn tuỳ ý các thông điệp giữa các node.

Định lý phát biểu: không hệ nào đồng thời bảo đảm cả C và A khi có partition. Chứng minh trực giác: partition cắt hệ thành hai nửa không nói chuyện được. Nếu nửa này nhận một ghi, nửa kia không thể biết → để trả lời một đọc bên nửa kia mà vẫn linearizable (thấy ghi mới), nó buộc phải chờ liên lạc phục hồi (mất A) hoặc trả giá trị cũ (mất C). Không có lối thoát thứ ba.

3. Vì sao P không phải lựa chọn — và "CA" là ảo tưởng?

Điểm sai cốt lõi của cách đọc "2 trong 3" là coi P ngang hàng C và A như thể chọn được. Nhưng C và A là thuộc tính bạn thiết kế, còn P là điều kiện môi trường áp lên bạn. Bạn không "bật/tắt" partition — cáp đứt, switch chết, GC pause dài, mạng nghẽn đều tạo partition, và trong một hệ nhiều máy chúng sẽ xảy ra.

Do đó "CA" (nhất quán + khả dụng, bỏ P) chỉ tồn tại trên một máy đơn không có mạng để mà phân mảnh. Ngay khi có từ hai node nối bằng mạng, bạn đã phải chịu P — nên lựa chọn thật luôn là CP hay AP:

flowchart TD
  P{"Mang co partition khong?"}
  P -->|"Khong (mang lanh)"| BOTH["Co the vua C vua A"]
  P -->|"Co"| CHOICE{"Node bi cat chon gi?"}
  CHOICE -->|"Giu linearizable"| CP["CP: tu choi phuc vu (mat A)"]
  CHOICE -->|"Van phuc vu"| AP["AP: tra loi co the cu (mat C)"]

Lần theo cơ chế: ghi cần 3 node xác nhận. Nhóm X (3 node) vừa đủ gom một majority quorum trong nội bộ → vẫn nhận ghi và đọc được, và vì mọi majority quorum đều giao nhau, nó giữ được một sự thật nhất quán. Nhóm Y (2 node) không thể gom nổi 3 → mọi ghi/đọc cần quorum đều bị từ chối (client bên Y bị treo/lỗi). Hệ hy sinh availability ở phía thiểu số để không bao giờ có hai phía cùng nhận ghi mâu thuẫn — đó chính là hành vi CP. Nếu thay vào đó ta cho nhóm Y cứ phục vụ bằng dữ liệu cục bộ (nới quorum), hệ thành AP: Y vẫn khả dụng nhưng có thể trả giá trị cũ và tạo xung đột phải hoà giải sau. Không có cấu hình nào cho cả "Y vẫn phục vụ" lẫn "linearizable" trong lúc partition — đúng như định lý.

4. PACELC — bức tranh đầy đủ hơn: còn cả latency

CAP chỉ nói về lúc partition, nhưng phần lớn thời gian mạng lành — và ngay cả lúc lành vẫn có một đánh đổi CAP bỏ sót: latency. PACELC (Abadi, 2012) mở rộng: nếu Partition thì chọn A hay C; Else (mạng lành) thì chọn Latency hay Consistency.

Ý là: kể cả không partition, muốn linearizability bạn vẫn phải phối hợp giữa các bản sao mỗi thao tác (bài 01, mục 5) → chậm hơn. Muốn nhanh (đọc từ bản gần nhất) thì phải nới nhất quán. Vì vậy một hệ AP như Cassandra thường là PA/EL (partition → A; else → thiên latency), còn etcd là PC/EC (luôn nghiêng consistency). PACELC nhắc: đánh đổi nhất quán không chỉ sống ở lúc sự cố hiếm, nó hiện diện mỗi thao tác dưới dạng latency.

5. Pitfall — "2 trong 3" và tưởng chọn được CA

❌ "He minh la CA: nhat quan + kha dung, khong lo partition"
   -> Ao tuong: khong the bo P trong he nhieu node. Mang SE phan manh.
   "CA" chi ton tai tren mot may don. Thuc te ban dang la CP hoac AP.

❌ "Chon 2 trong 3 mot lan cho mãi mãi"
   -> SAI: danh doi C-vs-A chi kich hoat KHI partition. Ngoai luc do co
   ca hai. Phan loai dung: "khi partition thi nghieng ve dau".

❌ "C trong CAP = nhat quan noi chung, nen causal cung dinh CAP"
   -> C o day nghia HEP = linearizability. Causal consistency VAN kha dung
   khi partition -> no khong bi ket trong danh doi gat cua CAP.

6. 📚 Đào sâu — nguồn gốc & tài liệu

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

• Bài 01 — Linearizability: "C" trong CAP chính là linearizability; "kém khả dụng khi partition" ở bài 01 được CAP hình thức hoá tại đây.
• Bài 02 — Causal consistency: mức nhất quán mạnh nhất vẫn khả dụng khi partition — nằm ngoài đánh đổi gắt của CAP, giải thích vì sao nó là "điểm ngọt".
• Bài 05 — Case study: etcd/ZooKeeper (CP) vs Cassandra (AP) là hiện thân cụ thể của lựa chọn trong bài này.
• Module 2 — Leaderless replication: quorum w + r > n và sloppy quorum là núm vặn CP↔AP thực tế.

8. Tóm tắt

• P không phải lựa chọn: mạng phân tán sẽ phân mảnh, nên P luôn phải chịu. "CA" chỉ có trên máy đơn.
• Đánh đổi thật chỉ bật khi partition: node bị cắt chọn C (từ chối để đúng) hay A (phục vụ nhưng có thể sai). Ngoài lúc đó có cả hai.
• Phân loại thực dụng: CP (etcd/ZooKeeper — hy sinh availability) vs AP (Cassandra — hy sinh linearizability).
• "C" trong CAP nghĩa hẹp = linearizability, không phải C của ACID; causal vẫn khả dụng khi partition nên không kẹt trong đánh đổi này.
• PACELC: kể cả mạng lành (Else), vẫn phải chọn Latency vs Consistency — nhất quán tính phí mỗi thao tác, không chỉ lúc sự cố.
• Cách chọn: mặc định "P luôn có", rồi hỏi từng loại dữ liệu — từ chối (CP) hay phục vụ có thể cũ (AP).

9. Tự kiểm tra

Bài tiếp theo: Consensus qua Raft — leader election, log replication, commit