Vấn đề Split-Brain - Cái gì và tại sao nó nguy hiểm?
Trước tiên, hãy tưởng tượng bạn đang điều hành một công ty với hai văn phòng ở Hà Nội và TP.HCM. Thông thường, cả hai văn phòng liên lạc với nhau để đưa ra quyết định chung. Nhưng một ngày nọ, đường dây điện thoại bị đứt.
Lúc này, cả hai văn phòng đều nghĩ: "Văn phòng kia có thể đã gặp sự cố, tôi phải đảm nhận vai trò lãnh đạo để công ty không ngừng hoạt động." Kết quả là cả hai đều tự xưng là trụ sở chính và đưa ra những quyết định mâu thuẫn nhau. Đây chính là split-brain problem.
Trong hệ thống phân tán, split-brain xảy ra khi network partition (mạng bị phân tách) khiến các nhóm nodes không thể liên lạc với nhau, và mỗi nhóm đều tự cho mình là nhóm còn sống và có quyền xử lý dữ liệu. Điều này dẫn đến:
Mâu thuẫn dữ liệu nghiêm trọng: Ví dụ, trong hệ thống ngân hàng, nếu một tài khoản có 1000$ và bị split-brain, nhóm A có thể xử lý giao dịch rút 800. Khi mạng được khôi phục, bạn sẽ có hai trạng thái mâu thuẫn: tài khoản còn 200$ và tài khoản còn 300$.
Mất tính nhất quán: Người dùng có thể nhận được kết quả khác nhau tùy thuộc vào việc họ kết nối với nhóm nào, phá vỡ niềm tin vào hệ thống.
Tại sao vấn đề này khó giải quyết?
Split-brain problem khó giải quyết vì nó nằm ở trái tim của một nghịch lý: làm sao để phân biệt giữa "node khác thực sự đã chết" và "node khác chỉ tạm thời không liên lạc được"? Trong cả hai trường hợp, triệu chứng đều giống nhau - bạn không nhận được phản hồi.
Giải pháp 1: Paxos Algorithm - Người tiên phong
Paxos được Leslie Lamport phát minh vào những năm 1980, chính là để giải quyết vấn đề này. Paxos hoạt động theo nguyên tắc "majority rule" (quy tắc đa số):
Cách Paxos ngăn chặn split-brain: Paxos yêu cầu phải có sự đồng ý từ majority (hơn một nửa) của tất cả nodes trước khi commit bất kỳ thay đổi nào. Nếu bạn có 5 nodes và bị chia thành nhóm 2 và nhóm 3, chỉ có nhóm 3 nodes mới có thể tiếp tục hoạt động vì chỉ có nhóm này đạt được majority.
Ví dụ thực tế: Trong hệ thống 5 nodes, khi network partition chia thành nhóm A (2 nodes) và nhóm B (3 nodes), chỉ nhóm B mới có thể xử lý các giao dịch ghi. Nhóm A sẽ từ chối tất cả giao dịch ghi để tránh tạo ra dữ liệu mâu thuẫn.
Giải pháp 2: Raft Algorithm - Phiên bản dễ hiểu hơn
Raft được Diego Ongaro và John Ousterhout phát triển vào 2013, với mục tiêu tạo ra một thuật toán "understandable" hơn Paxos nhưng vẫn giải quyết được cùng một vấn đề.
Cách Raft ngăn chặn split-brain: Raft sử dụng mô hình leader-follower rõ ràng. Chỉ có leader mới được phép xử lý giao dịch ghi, và leader chỉ được bầu chọn khi có sự đồng ý từ majority của cluster. Nếu leader mất liên lạc với majority, nó sẽ tự động từ chức và không xử lý giao dịch nào nữa.
Quy trình cụ thể trong Raft: Khi network partition xảy ra, nếu leader cũ chỉ còn liên lạc được với minority của nodes, leader này sẽ chuyển sang trạng thái follower. Trong khi đó, nhóm majority sẽ bầu chọn leader mới và tiếp tục hoạt động. Điều này đảm bảo chỉ có một leader duy nhất tại mọi thời điểm.
Tại sao cả hai đều chọn "sacrifice availability"?
Bạn có thể thắc mắc: tại sao không để cả hai nhóm đều hoạt động để tăng availability? Câu trả lời nằm ở bản chất của consistency. Nếu cho phép cả hai nhóm hoạt động độc lập, bạn sẽ tạo ra những thay đổi mâu thuẫn không thể hòa giải sau này.
Hãy nghĩ về điều này: bạn có thể hàn gắn một mạng bị đứt, nhưng bạn không thể "hàn gắn" dữ liệu mâu thuẫn một cách tự động và chính xác.
Câu hỏi để suy ngẫm
Để hiểu sâu hơn, hãy thử trả lời: Nếu bạn thiết kế một hệ thống chat nhóm thay vì hệ thống ngân hàng, liệu bạn có thể chấp nhận một chút inconsistency để đổi lấy availability cao hơn không? Tại sao use case ảnh hưởng đến lựa chọn thuật toán?