Hệ thống Dữ liệu Phân tán/Module 5 — Rắc rối của hệ phân tán: tổng quan
26/38
Bài 26 / 38~10 phútRắc rối của hệ phân tánMiễn phí lượt xem

Module 5 — Rắc rối của hệ phân tán: tổng quan

Những giả định vỡ khi lên nhiều máy: mạng không tin cậy, đồng hồ không tin cậy, causal order, và partial failure. Nền cho consistency & consensus.

TL;DR: Bốn module trước xây các cơ chế phân tán (replication, partitioning, transaction) như thể mạng và máy đều đáng tin. Module này gỡ giả định đó và nhìn thẳng vào những thứ vỡ khi lên nhiều máy. Một sự thật khó chịu chạy xuyên suốt: trong hệ phân tán, bạn không phân biệt được một node chậm với một node đã chết — và từ đó đổ ra mọi khó khăn. Ta đi qua bốn nguồn rắc rối: mạng không tin cậy (timeout, retry, 8 fallacies), đồng hồ không tin cậy (clock skew, monotonic vs wall clock), causal order (suy thứ tự bằng nhân quả khi không tin được đồng hồ), và partial failure (một phần chết, split-brain, và fencing token chống zombie). Đây là nền để hiểu vì sao consistency & consensus (Module 6) vừa khó vừa cần thiết.

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

Ở Module 4, 2PC "blocking" vì coordinator có thể chết giữa chừng và participant không biết chờ tới bao giờ. Câu "không biết chờ tới bao giờ" không phải chi tiết phụ — nó là triệu chứng của một căn bệnh nền mà mọi hệ phân tán mắc phải: các node chỉ nói chuyện qua mạng, mà mạng thì có thể trễ tuỳ ý, mất gói, hoặc chia cắt; và không có tín hiệu trung thực nào cho biết bên kia còn sống hay đã chết.

Module này không dạy một cơ chế mới để xây. Nó dạy bạn nhìn ra các chế độ lỗi mà máy đơn không có — để ở các module sau, khi thiết kế, bạn không rơi vào những cái bẫy tinh vi (retry mù làm trùng giao dịch, LWW mất dữ liệu do đồng hồ lệch, zombie ghi đè sau khi bị coi là chết). Hiểu sâu "cái gì vỡ và vì sao" là điều kiện để đánh giá đúng mọi giải pháp phân tán về sau.

Sau module này bạn sẽ

  • Explain mạng không tin cậy: timeout, retry, và 8 fallacies of distributed computing
  • Explain đồng hồ không tin cậy: clock skew, monotonic vs wall clock
  • Explain causal order qua happened-before và vector clock
  • Explain partial failure, split-brain và fencing token chống split-brain

Lộ trình module

flowchart LR
  A["01 Mang<br/>khong tin cay"] --> B["02 Dong ho<br/>khong tin cay"]
  B --> C["03 Causal order<br/>happened-before"]
  C --> D["04 Partial failure<br/>+ fencing token"]

Bắt đầu ở mạng không tin cậy — đặt nền "không phân biệt được chậm với chết", timeout như một phỏng đoán, và retry cần idempotency. Rồi đồng hồ không tin cậy đóng nốt lối "dựa timestamp để biết thứ tự". Vì cả mạng lẫn đồng hồ đều bất khả tín, causal order đổi câu hỏi sang "cái gì ảnh hưởng cái gì" (happened-before, vector clock). Khép bằng partial failure & fencing token — split-brain do process pause, và cách chặn zombie một cách cơ học.

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

  • Module 1–4 của khoá — hiểu replication, partitioning, transaction phân tán; module này giải thích vì sao các cơ chế đó khó (mạng/đồng hồ/lỗi từng phần).
  • Có ích: đã học TCP/UDP và lỗi mạng thường gặp (khoá networking), latency & RTT, và vector clock (khoá thuật toán) — module recall trực tiếp tới các bài đó.

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

  • Giữ một câu hỏi xuyên suốt: "Nếu bên kia không trả lời, tôi có cách nào biết chắc nó chết chưa?" — câu trả lời luôn là "không", và mọi cơ chế trong module là cách sống chung với sự bất định đó.
  • Chú ý các lỗi tinh vi: chúng không làm hệ sập ngay mà gây sai âm thầm (trùng giao dịch, mất ghi, hỏng file) chỉ trong các tình huống hiếm — đó là lý do phải hiểu cơ chế chứ không chỉ "chạy thử thấy ổn".
  • Nối liên tục về Module 6: vì không có máy dò chết hoàn hảo và không tin được thời gian, hệ cần một cách để đa số node đồng ý về sự thật — đó là consensus.

Bài này có giúp bạn hiểu bản chất không?

Hỏi đáp về bài này

Chưa có câu hỏi

Đặt câu hỏi

Có gì chưa rõ trong bài? Đặt câu hỏi đầu tiên — câu trả lời từ cộng đồng giúp bạn (và người sau).

Đặt câu hỏi đầu tiên