Distributed Systems Cơ bản

Khi một lời gọi hàm trong cùng process thất bại, ta biết chắc nó đã thất bại. Khi một lời gọi qua mạng hết thời gian chờ, ta không biết gì: request có thể chưa rời client, đã đến server nhưng chưa làm, đã commit, hoặc đã commit nhưng response mất. Đó là partial failure, và gần như mọi chủ đề khó trong hệ phân tán bắt nguồn từ nó.

Bản đồ bài viết

Vấn đề	Bài	Kết luận chính
Timeout không cho biết server đã làm gì	Tám ngộ nhận	Một RPC có bốn điểm hỏng; thao tác có side effect cần idempotency key
Thử lại mà không làm lỗi nặng hơn	Retry, backoff và jitter	Full jitter, retry budget, chỉ một tầng retry
Đồng hồ các máy không khớp	Logical clock	L(a) < L(b) chưa chứng minh nhân quả; LWW theo wall clock mất dữ liệu
Một dependency chậm kéo sập cả API	Circuit breaker & bulkhead	Timeout luôn cần; bulkhead cô lập tài nguyên; breaker fail fast khi lỗi hoặc call chậm vượt ngưỡng
Một thao tác nghiệp vụ trải qua nhiều service và một bước sau bị lỗi	Saga	Bù trừ là hoàn tác về nghĩa, chạy theo thứ tự ngược; lưu trạng thái saga; bước và bước bù trừ phải idempotent

Thứ tự đọc gợi ý: tám ngộ nhận, rồi retry (hệ quả trực tiếp của partial failure), rồi logical clock.

Cùng ranh giới ở các nhóm khác

Nhóm	Biểu hiện của partial failure
Kafka là distributed log	Commit offset không xác nhận side effect ngoài Kafka đã thành công
ACID trong PostgreSQL	Kết nối đứt đúng lúc gửi COMMIT: client không biết transaction đã commit chưa
Cache-aside	Cache và database là hai hệ thống, không cập nhật atomic cùng nhau
Timeout budget	Ngân sách thời gian cho toàn chuỗi retry

Nhóm này vẫn đang được bổ sung.