Module 6 — Nhất quán & Đồng thuận: tổng quan

TL;DR: Module cuối khép 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? Ta đi từ đảm bảo mạnh nhất — linearizability (hệ hành xử như chỉ có một bản dữ liệu, mọi thao tác thấy giá trị mới nhất) — xuống mức yếu hơn nhưng khả dụng khi partition — causal consistency (giữ đúng nhân quả, không cần thứ tự toàn cục). Rồi đọc lại CAP đúng nghĩa: partition không tránh được, nên thực chất là chọn nhất quán hay khả dụng khi mạng phân mảnh. Cuối cùng là consensus qua Raft — cỗ máy để cả cụm chốt "ai là leader" và "log theo thứ tự nào" một cách an toàn (leader election, log replication, commit theo đa số), nền của failover không split-brain và khoá phân tán. Khép bằng case study etcd/ZooKeeper (CP) vs Cassandra (AP) — nơi cả track hội tụ thành một quyết định chọn hệ.

Vì sao module này tồn tại

Năm module trước dựng nên một hệ phân tán hoạt động: dữ liệu được nhân bản (Module 2), phân mảnh (Module 3), giao dịch xuyên node (Module 4), và ta đã thấy những rắc rối vốn có — mạng và đồng hồ không tin cậy, không phân biệt được node chậm với node chết (Module 5). Nhưng một câu hỏi cốt tử còn treo: khi nhiều bản sao và không tin được ai, làm sao cả hệ đồng ý một sự thật duy nhất?

Đó là câu hỏi về nhất quán (mọi người thấy gì) và đồng thuận (làm sao chốt một quyết định). Nó không phải lý thuyết suông: "ai là primary sau failover?", "ai giữ khoá này?", "số dư mới nhất là bao nhiêu?" đều quy về đây. Làm sai sinh ra split-brain và mất dữ liệu — những sự cố tồi tệ nhất. Module này cho bạn ngôn ngữ để nói chính xác về các mức đảm bảo, hiểu cái giá của mỗi mức, và biết công cụ (consensus) tạo ra đảm bảo mạnh.

Sau module này bạn sẽ

• Distinguish linearizability vs causal consistency và chi phí của mỗi mức
• Explain CAP đúng nghĩa: khi partition, chọn consistency hay availability
• Explain consensus qua Raft: leader election, log replication, commit
• Compare consensus store (etcd/ZooKeeper) vs quorum store (Cassandra) theo đảm bảo và use case

Lộ trình module

flowchart LR
  A["01 Linearizability<br/>manh nhat + cai gia"] --> B["02 Causal<br/>yeu hon, kha dung"]
  B --> C["03 CAP dung nghia<br/>P bat buoc"]
  C --> D["04 Consensus/Raft<br/>chot mot su that"]
  D --> E["05 Case study<br/>etcd vs Cassandra"]

Bắt đầu ở linearizability — đảm bảo mạnh nhất ("như một bản duy nhất") và vì sao nó đắt. Rồi causal consistency: bỏ bớt gì để rẻ hơn và vẫn khả dụng khi partition. Có hai mức trong tay, CAP đúng nghĩa hình thức hoá đánh đổi: partition bắt buộc, nên chọn C hay A khi nó xảy ra. Rồi consensus qua Raft — cỗ máy chốt một sự thật an toàn, chống split-brain bằng đa số. Khép bằng case study: etcd/ZooKeeper (CP) vs Cassandra (AP), nơi mọi khái niệm biến thành một quyết định chọn hệ thật.

Yêu cầu trước khi bắt đầu

• Module 5 (Rắc rối phân tán) — mạng/đồng hồ không tin cậy, causal order, fencing: nền để hiểu vì sao consensus vừa khó vừa cần.
• Bắt buộc có ích: ở track thuật toán bạn đã dựng quorum, vector clock, và Raft ở mức thuật toán — module này gọi lại (<Recall>) và nâng chúng lên tầng hệ dữ liệu. Xem lại nếu đã quên.
• Nối tiếp: linearizability đối chiếu với serializability (Module 4) — hai trục dễ nhầm.

Cách học module này hiệu quả

• Giữ một câu hỏi xuyên suốt: thao tác này có THẬT SỰ cần một sự thật mới nhất duy nhất không? — nếu có thì trả giá (consensus/linearizable); nếu không thì mức yếu hơn rẻ hơn là đủ.
• Với mỗi mức nhất quán, luôn hỏi hai vế: đảm bảo gì và giá bao nhiêu (latency, khả dụng khi partition). Không có mức nào "tốt nhất" — chỉ có mức đúng cho một loại dữ liệu.
• Đây là module cuối course: cố ý ghép ngược về năm module trước ở bài case study. Khi học, tự hỏi mỗi khái niệm đứng ở đâu trong bức tranh "đo hệ → replication → partitioning → transaction → rắc rối → đồng thuận".