Hệ phân tán

Khi dữ liệu và xử lý nằm trên nhiều máy, những điều hiển nhiên trên một máy không còn đúng: mạng có thể mất gói hoặc chậm bất thường, đồng hồ các máy lệch nhau, một máy có thể chết giữa chừng. Phần này gồm các khái niệm nền mà database phân tán, message broker và microservices đều dựa vào.

Trang	Trả lời câu hỏi
Replication	Giữ nhiều bản sao thế nào; một leader, nhiều leader hay không leader
Partitioning	Chia dữ liệu ra nhiều máy thế nào; thêm máy thì di chuyển dữ liệu ra sao
Nhất quán & CAP	Đọc từ bản sao thì thấy gì; CAP, PACELC nói gì thật sự
Đồng thuận	Nhiều máy thống nhất một giá trị, bầu leader, tránh split-brain
Thời gian & thứ tự	Vì sao không dùng đồng hồ máy để sắp thứ tự sự kiện
Commit phân tán	Ghi nguyên tử trên nhiều nơi; 2PC và vì sao ít dùng; saga và outbox dùng thay thế
Xử lý lỗi & idempotency	Timeout, retry, “exactly-once” thực chất là gì; phát hiện node chết, gossip và SWIM
Distributed lock	Khoá giữa nhiều máy: lease, fencing token, Redis vs etcd vs database

Phần cài đặt cụ thể nằm ở nơi khác và dẫn link về đây: replication và CDC của MySQL (chương 9), sharding trên MySQL (chương 10), sinh ID phân tán (Sinh ID).

Mô hình lỗi: thuật toán giả định điều gì

Mỗi thuật toán phân tán chỉ đúng dưới một số giả định về việc node và mạng có thể hỏng ra sao. Các trang sau dùng những giả định này, nên cần gọi tên chúng.

Node có thể hỏng theo ba kiểu, từ dễ xử lý tới khó:

Kiểu	Node làm gì khi hỏng	Ví dụ
Crash-stop	Dừng hẳn và không bao giờ quay lại	Máy bị thay, container bị xoá
Crash-recovery	Dừng, rồi có thể khởi động lại; mất những gì trong RAM, còn những gì đã ghi xuống đĩa	Process bị kill rồi chạy lại, máy khởi động lại. Đây là kiểu mà database, Raft, hàng đợi đều giả định
Byzantine	Làm bất cứ điều gì, kể cả gửi thông tin sai hay nói dối có chủ đích	Phần cứng hỏng làm sai dữ liệu, node bị chiếm quyền, các bên không tin nhau

Bài báo Raft ghi rõ giả định của nó: server hỏng bằng cách dừng lại, có thể khôi phục từ dữ liệu trên đĩa rồi vào lại cluster, và Raft đảm bảo an toàn dưới mọi điều kiện không Byzantine. Hầu hết hệ thống backend cũng giả định như vậy, vì mọi node đều do mình vận hành và không nói dối nhau. Chống Byzantine tốn hơn nhiều (thường cần 3f + 1 node để chịu được f node gian lận, thay vì 2f + 1), nên chỉ dùng ở nơi các bên không tin nhau, như blockchain. Dữ liệu bị hỏng do phần cứng thì được chặn bằng checksum, không bằng thuật toán chống Byzantine.

Mạng có thể được giả định theo ba cách:

Giả định	Nghĩa là	Thực tế
Đồng bộ (synchronous)	Có giới hạn trên đã biết cho thời gian gửi một gói và độ lệch đồng hồ	Không đúng với mạng thật: gói có thể chậm tuỳ ý vì mạng nghẽn, GC pause, máy quá tải
Bất đồng bộ (asynchronous)	Không có giới hạn nào cho thời gian, gói chỉ đến "rồi sẽ đến"	An toàn để giả định, nhưng quá khắt khe: FLP chứng minh trong mô hình này không thuật toán đồng thuận tất định nào luôn đi tới quyết định nếu có dù chỉ một node có thể chết (Đồng thuận)
Đồng bộ một phần (partially synchronous)	Phần lớn thời gian mạng hoạt động trong giới hạn, nhưng thỉnh thoảng vượt giới hạn trong một khoảng không biết trước	Mô hình gần thực tế nhất, và là giả định của Raft, Paxos, các failure detector

Hệ quả thực tế cho người làm backend: qua mạng không phân biệt chắc chắn được một node đã chết với một node chỉ đang chậm. Mọi thứ phát hiện lỗi đều chỉ là đoán, bằng timeout, phi accrual hay SWIM (Phát hiện một node đã chết), và có lúc đoán sai. Vì vậy các thuật toán tốt dùng thời gian để tiến lên (bầu leader mới, retry) chứ không dùng để đảm bảo đúng. Bài báo Raft viết rằng Raft không dựa vào thời gian để giữ log nhất quán, đồng hồ sai hay gói chậm bất thường tệ nhất chỉ làm hệ thống tạm không phục vụ được. Còn ở tầng ứng dụng, khi một node bị coi là chết nhầm vẫn có thể tỉnh dậy và ghi tiếp, thì phải có lease và fencing token để chặn nó (Distributed lock).

Nguồn tham khảo

Đã đối chiếu (đọc nguồn ngày 2026-10-28):

Nguồn	Dùng cho phần
Diego Ongaro, John Ousterhout, In Search of an Understandable Consensus Algorithm (Raft), 2014	Server hỏng bằng cách dừng, khôi phục từ stable storage rồi vào lại cluster; an toàn dưới mọi điều kiện không Byzantine; không dựa vào thời gian để giữ log nhất quán, tệ nhất chỉ ảnh hưởng availability
Michael Fischer, Nancy Lynch, Michael Paterson, Impossibility of Distributed Consensus with One Faulty Process, JACM 1985	Không giao thức đồng thuận hoàn toàn bất đồng bộ nào chịu được dù chỉ một process chết không báo trước

Từ kiến thức chung, chưa đối chiếu lần này: mô hình đồng bộ một phần (Dwork, Lynch, Stockmeyer, 1988); chống Byzantine cần 3f + 1 node (Lamport, Shostak, Pease, 1982); Paxos và các failure detector giả định đồng bộ một phần.