Lý thuyết, thuật toán và giao thức phân tán là nền tảng để hiểu distributed system. Khi học phần này, không nên chỉ học thuộc kết luận; quan trọng hơn là hiểu sự đánh đổi giữa consistency, availability, fault tolerance, consensus, performance và độ phức tạp khi triển khai trong thực tế của các phương án khác nhau.

Một vài node dịch vụ đều nói mình đúng, client nên tin ai?

Trong các hệ thống backend hằng ngày, vấn đề này thường không cực đoan đến vậy. Redis master-slave, ZooKeeper, etcd, Nacos và database replication thường gặp machine crash, network chập chờn, disk failure, process restart hơn. Node thường không cố ý lừa bạn; nó chỉ không phản hồi, phản hồi chậm hoặc tạm thời mất kết nối với cluster.

Một scheduled task được deploy với 3 instance. Đến 2 giờ sáng, rốt cuộc ai sẽ chạy batch task này?

Nếu cả 3 instance cùng chạy, dữ liệu có thể bị xử lý trùng; nếu cả 3 instance đều chờ instance khác chạy, task sẽ bị bỏ sót. Cache cluster, message queue, configuration center và distributed lock cũng gặp vấn đề tương tự: sau khi số node tăng lên, hệ thống phải có người quyết định “ai phụ trách việc gì”, “hiện tại ai còn sống” và “thay đổi lần này có hiệu lực theo thứ tự nào”.

Trước khi bắt đầu, hãy xem hai tình huống thường gặp:

1. Load balancing: Vì có quá nhiều người truy cập, website của chúng ta được triển khai trên nhiều server cùng cung cấp một dịch vụ giống nhau, nhưng dữ liệu lưu trên mỗi server lại khác nhau. Để bảo đảm request được phản hồi chính xác, các request có cùng tham số (key) (chẳng hạn request từ cùng một IP hoặc request của cùng một user) cần được gửi đến cùng một server để xử lý.
2. Distributed cache: Vì lượng dữ liệu cache quá lớn, chúng ta triển khai nhiều cache server cùng cung cấp dịch vụ cache. Dữ liệu cache cần được phân bố trên các cache server này một cách đồng đều nhất có thể, và có thể tìm thấy cache server tương ứng thông qua key.

Bối cảnh

Trong hệ thống phân tán, chia sẻ state giữa các node là một nhu cầu cơ bản.

Một cách đơn giản là broadcast tập trung: node trung tâm đồng bộ thông tin tới tất cả node khác. Cách này phù hợp với hệ thống tập trung, nhưng có nhược điểm rõ ràng: khi số lượng node tăng, hiệu quả đồng bộ giảm (độ phức tạp O(N)), đồng thời quá phụ thuộc vào node trung tâm và có rủi ro single point of failure.

Bối cảnh

Thuật toán Paxos là một thuật toán consensus của hệ thống phân tán do Leslie Lamport đề xuất vào năm 1990. Đây là một trong những thuật toán consensus phân tán đầu tiên được công nhận rộng rãi (với điều kiện không xảy ra vấn đề các tướng Byzantine, tức là không có node độc hại).

Bài viết do SnailClimb và Xieqijun cùng thực hiện.

1 Bối cảnh

Trong kiến trúc Internet ngày nay, để chịu được lưu lượng khổng lồ, hệ thống thường cần mở rộng bằng cách bổ sung máy theo chiều ngang. Khi số lượng máy tăng lên, các sự cố như máy sập, mất mạng trở thành chuyện thường ngày. Làm thế nào để nhóm server có thể mất kết nối bất cứ lúc nào này giữ được nhịp hoạt động nhất quán và không cung cấp dữ liệu sai lệch ra bên ngoài? Đây là lúc distributed consensus algorithm phát huy tác dụng.