Module 6 — Tổng kết & cheat sheet

TL;DR: Module 6 trả lời câu hỏi khó nhất của hệ phân tán — làm sao nhiều node đồng ý một sự thật? Linearizability (như một bản duy nhất, có recency) là đảm bảo mạnh nhất nhưng đắt và mất khả dụng khi partition; causal consistency yếu hơn (chỉ giữ nhân quả) nhưng khả dụng khi partition và rẻ. CAP đúng nghĩa: P bắt buộc, nên chọn C hay A khi partition. Consensus qua Raft (leader election, log replication, commit theo đa số) là cỗ máy chốt một sự thật an toàn, chống split-brain. Case study: etcd/ZooKeeper (CP, khoá/config) vs Cassandra (AP, dữ liệu lớn). Đây cũng là trang khép cả track — sáu module hợp thành một bức tranh về hệ dữ liệu phân tán. Bookmark trước phỏng vấn.

Đã đi qua những gì

Bắt đầu bằng linearizability: ảo giác "chỉ có một bản dữ liệu", mỗi thao tác xảy ra tức thời tại một điểm giữa invoke/response, tôn trọng real-time → recency (đọc sau ghi luôn thấy giá trị mới). Mạnh, nhưng cần phối hợp mỗi thao tác nên chậm và mất khả dụng khi partition; và đừng nhầm nó với serializability (một object + real-time vs nhiều giao dịch + "tuần tự nào đó"). Rồi causal consistency: giữ đúng thứ tự các thao tác có nhân quả (happened-before, theo vector clock), thả tự do cho cặp đồng thời — không recency, nhưng là mức mạnh nhất vẫn khả dụng khi partition, và rẻ vì chỉ theo dõi dependency cục bộ. Rồi CAP đúng nghĩa: partition không phải lựa chọn (mạng sẽ phân mảnh), nên đánh đổi thật chỉ bật khi partition — chọn CP (từ chối để đúng) hay AP (phục vụ nhưng có thể cũ); "C" ở đây nghĩa hẹp là linearizability, và PACELC nhắc rằng ngay lúc mạng lành vẫn phải chọn latency-vs-consistency. Rồi consensus qua Raft: chốt một giá trị/thứ tự duy nhất qua ba mảnh — leader election (theo term, đa số phiếu), log replication (leader sao chép sang follower), commit (khi đạt đa số) — và vì hai đa số luôn giao nhau nên không bao giờ split-brain. Khép bằng case study: etcd/ZooKeeper (consensus, CP — khoá/config/bầu leader) vs Cassandra (quorum, AP — dữ liệu lớn, khả dụng cao), và vì sao kiến trúc thật dùng cả hai.

flowchart LR
  A["Linearizability<br/>manh + dat"] --> B["Causal<br/>yeu hon, kha dung"]
  B --> C["CAP: P bat buoc<br/>chon C hay A"]
  C --> D["Consensus/Raft<br/>chot mot su that"]
  D --> E["etcd (CP)<br/>vs Cassandra (AP)"]

🗺️ Cheat sheet

📖 Glossary module

⚠️ Pitfall tổng hợp

• Nhầm linearizability với serializability: một object + real-time vs nhiều giao dịch + "tuần tự nào đó". Đúng: tách hai trục; cần cả hai là strict serializability.
• Tưởng quorum w+r>n là linearizable: không — lệch định thời vẫn cho đọc cũ. Đúng: thêm read-repair đồng bộ / đọc qua leader.
• Tưởng causal có recency: causal không đảm bảo thấy giá trị mới nhất. Đúng: cần recency thì lên linearizable.
• Đọc CAP là "chọn 2/3" / "hệ CA": P bắt buộc, không bỏ được. Đúng: hỏi "khi partition thì CP hay AP".
• "Có leader là an toàn": một ghi chỉ bền khi đã committed (đạt đa số). Đúng: chỉ báo thành công sau ngưỡng đa số.
• "Consensus chịu được mọi lỗi": cần đa số sống; 2f+1 chịu f. Đúng: chọn số node lẻ theo mức chịu lỗi cần.
• Khoá phân tán trên quorum store: thiếu recency → chạy trùng. Đúng: khoá đặt ở consensus store (etcd/ZooKeeper).

✅ Self-assessment

Bạn đã đạt module này nếu trả lời được:

• Phân biệt được linearizability vs causal consistency và chi phí của mỗi mức
  • Nếu chưa: đọc lại bài 01 — Linearizability (mục 2-5) và bài 02 — Causal consistency (mục 2-4).
• Giải thích được CAP đúng nghĩa: khi partition, chọn consistency hay availability
  • Nếu chưa: đọc lại bài 03 — CAP đúng nghĩa (mục 2-3).
• Giải thích được consensus qua Raft: leader election, log replication, commit
  • Nếu chưa: đọc lại bài 04 — Consensus/Raft (mục 3-4).
• So sánh được consensus store (etcd/ZooKeeper) vs quorum store (Cassandra) theo đảm bảo và use case
  • Nếu chưa: đọc lại bài 05 — Case study (mục 2-5).

🚀 What's next — khép track, mở đường

Đây là module cuối của course Hệ thống Dữ liệu Phân tán (Tier 1, DDIA Part II). Nhìn lại toàn bộ hành trình:

flowchart LR
  M1["M1 Tu duy do he<br/>reliability, tail latency"] --> M2["M2 Replication"]
  M2 --> M3["M3 Partitioning"]
  M3 --> M4["M4 Transaction phan tan<br/>2PC, saga"]
  M4 --> M5["M5 Rac roi phan tan<br/>clock/network khong tin cay"]
  M5 --> M6["M6 Nhat quan &<br/>dong thuan"]

Bạn đi từ cách đo một hệ dữ liệu, qua nhân bản và phân mảnh để mở rộng, tới giao dịch xuyên node và những rắc rối vốn có của phân tán, và khép lại ở nhất quán & đồng thuận — nơi mọi đánh đổi trước đó quy về một câu hỏi: cần một sự thật mới nhất duy nhất tới mức nào, và trả giá gì cho nó? Với bộ khung này bạn đã có thể đọc kiến trúc của các hệ thật (Kafka, Cassandra, etcd, Spanner) và lập luận trade-off thay vì học vẹt tên sản phẩm.

Chặng tiếp theo của track Hệ thống Dữ liệu Quy mô lớn là Tier 2 — Phái sinh (derived data): batch/stream processing, event log (Kafka), CDC, materialized view — cách biến đổi dữ liệu đã lưu thành dạng phục vụ đọc. Nhiều mối chỉ được nhắc "để dành Tier 2" (outbox/CDC, exactly-once, event sourcing) sẽ được đào sâu ở đó.

📚 Tài liệu mở rộng

• Sách: Designing Data-Intensive Applications (Kleppmann) — Chương 9 "Consistency and Consensus" (nguồn chính của cả module) + Chương 5 (replication, vector clock).
• Paper: Herlihy & Wing (1990), "Linearizability" — định nghĩa gốc nhất quán mạnh.
• Paper: Gilbert & Lynch (2002), "Brewer's Conjecture..." — chứng minh định lý CAP; Brewer (2012) "CAP Twelve Years Later".
• Paper: Ongaro & Ousterhout (2014), "In Search of an Understandable Consensus Algorithm (Raft)"; Lamport (1998) "The Part-Time Parliament" (Paxos).
• Paper: DeCandia et al. (2007), "Dynamo" — nền của Cassandra (AP, quorum tunable).