Consistency và Consensus

Giữa consistency và consensus, cái nào quan trọng hơn trong việc ra quyết định? Nếu một tổ chức có consistency cao nhưng thiếu consensus, điều gì sẽ xảy ra?

Nếu consensus quan trọng hơn, điều đó có nghĩa là sự đồng thuận giữa các thành viên trong tổ chức là yếu tố quyết định sự thành công. Khi mọi người cùng đồng ý về một hướng đi, sự hợp tác và tinh thần làm việc nhóm sẽ mạnh hơn. Ngược lại, nếu chỉ có consistency mà không có consensus, tổ chức có thể hoạt động ổn định nhưng dễ gặp phải sự phản đối hoặc mất động lực từ các thành viên.

Trong các mô hình consistency, bạn nghĩ mô hình nào phù hợp nhất cho một hệ thống như Facebook News Feed? Eventual Consistency

Tại sao Raft được ưa chuộng trong các hệ thống hiện đại?

1. Raft đơn giản hơn Paxos ở điểm nào?

• Cấu trúc rõ ràng hơn: Raft chia bài toán đồng thuận thành ba phần: leader election (bầu leader), log replication (nhân bản log), và safety (an toàn dữ liệu). Điều này giúp dễ hiểu hơn so với Paxos, vốn có nhiều biến thể và thuật toán phức tạp.

• Dễ triển khai hơn: Paxos có nhiều bước xử lý phức tạp để đảm bảo sự đồng thuận, trong khi Raft đưa ra một cách tiếp cận trực quan, đặc biệt với cơ chế bầu leader rõ ràng.

• Hiệu suất tốt hơn trong thực tế: Paxos đòi hỏi nhiều vòng trao đổi tin nhắn hơn, trong khi Raft tối ưu hóa bằng cách tập trung quyền quyết định vào leader duy nhất.

2. Vậy khi nào nên dùng Paxos thay vì Raft?

Raft tuy dễ triển khai nhưng Paxos vẫn có lợi thế trong một số trường hợp, ví dụ như:

• Khi không có một leader cố định: Paxos không yêu cầu một node làm leader, giúp tăng tính linh hoạt.

• Môi trường có lỗi Byzantine (Byzantine Faults): Nếu cần đảm bảo an toàn khi có node độc hại hoặc gửi thông tin sai lệch, Paxos (hoặc các biến thể như Byzantine Paxos) có thể phù hợp hơn.

Nếu một hệ thống sử dụng Raft nhưng leader bị lỗi liên tục, điều gì sẽ xảy ra? Hệ thống sẽ xử lý thế nào?

1. Điều gì xảy ra khi leader bị lỗi liên tục?

Raft hoạt động dựa trên cơ chế Leader-based Consensus, tức là mọi ghi chép vào log phải thông qua leader. Khi leader chết, hệ thống sẽ thực hiện:

1. Phát hiện lỗi: Các follower sẽ không nhận được heartbeat từ leader trong một khoảng thời gian (timeout).

2. Bầu cử leader mới: Một follower sẽ tự đề cử (candidate), gửi RequestVote RPC đến các node khác để tranh cử.

3. Trở thành leader (nếu đủ phiếu bầu): Nếu đạt được đa số phiếu (quorum), node đó trở thành leader mới và bắt đầu gửi heartbeat.

4. Tiếp tục xử lý yêu cầu: Hệ thống hoạt động bình thường cho đến khi leader mới lại gặp lỗi.

Nhưng nếu leader cứ hỏng mãi?

• Quá trình bầu cử diễn ra liên tục, khiến hệ thống bị gián đoạn.

• Trong lúc bầu cử, hệ thống không thể xử lý yêu cầu ghi dữ liệu (write requests bị chặn).

• Nếu timeout đặt quá ngắn, có thể xảy ra split vote (chia phiếu), làm chậm quá trình bầu cử.

2. Vậy Raft giải quyết vấn đề này thế nào?

Raft có một số cơ chế để hạn chế việc bầu leader quá thường xuyên:

✔ Randomized Election Timeout: Mỗi node có một timeout khác nhau, giúp giảm khả năng xảy ra split vote.

✔ Stable Leader Term: Khi leader được bầu, nó sẽ giữ vị trí đến khi thực sự mất kết nối hoặc gặp lỗi.

✔ Pre-Vote Mechanism (Cải tiến mới): Một số hệ thống như etcd sử dụng cơ chế này để kiểm tra trước khi chính thức tổ chức bầu cử, giúp tránh bầu leader không cần thiết.

Thuật toán Paxos triển khai sao?

1. Paxos hoạt động như thế nào?

Paxos có ba vai trò chính:

• Proposer (Người đề xuất): Đề xuất một giá trị để đạt đồng thuận.

• Acceptor (Người chấp nhận): Nhận và chấp nhận giá trị từ proposer.

• Learner (Người học): Nhận kết quả cuối cùng của thuật toán (thường là các client hoặc database).

Quy trình hoạt động của Paxos gồm hai pha chính:

📌 Pha 1: Chuẩn bị (Prepare Phase)

1. Proposer chọn một số sequence number (n) duy nhất và gửi một đề nghị "prepare(n)" đến các acceptor.

2. Acceptor phản hồi nếu n lớn hơn tất cả các số đã thấy trước đó và cam kết không chấp nhận bất kỳ số nào nhỏ hơn n. Nếu acceptor đã chấp nhận một giá trị trước đó, nó sẽ trả về giá trị đó cùng với số sequence number tương ứng.

📌 Pha 2: Chấp nhận (Accept Phase)

1. Nếu proposer nhận đủ số phản hồi (đa số quorum), nó gửi một yêu cầu "accept(n, v)" với giá trị v (v có thể là giá trị được gửi trước đó hoặc một giá trị mới nếu chưa có gì).

2. Acceptor nhận "accept(n, v)" và nếu số n vẫn là số lớn nhất mà nó từng thấy, nó sẽ chấp nhận giá trị v.

Cuối cùng, nếu một giá trị v được accept bởi đa số acceptors, thì giá trị này trở thành giá trị được đồng thuận. Các learners sẽ nhận kết quả này để cập nhật trạng thái hệ thống.

Raft có phù hợp với hệ thống yêu cầu hiệu suất rất cao không?

Raft phù hợp nhất với loại hệ thống nào?

✔ Hệ thống phân tán cần tính nhất quán cao, hiệu suất ổn định (etcd, Consul, Kubernetes).

✔ Hệ thống có số lượng node vừa phải (~vài chục node) để tránh leader bottleneck.

✔ Hệ thống có workload chủ yếu là đọc (read-heavy), ghi ở mức trung bình.

🚫 Không phù hợp với hệ thống yêu cầu ghi tốc độ cực cao (write-heavy) hoặc phân tán cực rộng (geo-distributed systems).