Đồng Thuận Phân Tán Raft: Leader Election, Log Replication & Bài Toán Phân Mảnh Mạng

Bản Chất Của Vấn Đề Đồng Thuận (Consensus Problem)

Trong một hệ thống bao gồm nhiều máy chủ độc lập giao tiếp qua mạng internet không tin cậy (Unreliable Network), làm thế nào để tất cả các nút cùng nhất trí về một chuỗi nhật ký sự kiện duy nhất, ngay cả khi một số máy chủ bị crash, gói tin bị trễ hoặc mạng bị đứt gãy?

Trước khi Raft xuất hiện vào năm 2014, Paxos là thuật toán đồng thuận tiêu chuẩn. Tuy nhiên, Paxos nổi tiếng là cực kỳ phức tạp và trừu tượng, tạo ra khoảng cách rất lớn giữa lý thuyết hàn lâm và khả năng hiện thực hóa an toàn trong mã nguồn sản xuất.

Raft được thiết kế với mục tiêu cốt lõi: Dễ hiểu (Understandability) và phân rã tường minh bài toán đồng thuận thành ba bài toán con độc lập:

1. Bầu chọn Leader (Leader Election): Khi Leader cũ chết, một Leader mới phải được bầu chọn an toàn.
2. Sao chép nhật ký (Log Replication): Leader nhận lệnh từ client, ghi vào log của mình và ép buộc các nút Follower sao chép đồng bộ.
3. An toàn trạng thái (Safety Invariants): Bảo đảm không bao giờ có hai nút áp dụng hai lệnh khác nhau tại cùng một chỉ mục vào máy trạng thái (State Machine).

Ba Trạng Thái Máy & Chu Kỳ Nhiệm Kỳ (Terms)

Mỗi nút trong cụm Raft luôn ở một trong ba trạng thái:

• Leader: Nhận mọi request từ client, điều phối việc ghi log và gửi nhịp tim (Heartbeat).
• Follower: Trạng thái bị động, chỉ phản hồi RPC từ Leader và Candidate.
• Candidate: Trạng thái chuyển giao khi chuẩn bị thu thập phiếu bầu để trở thành Leader mới.

Thời gian trong Raft được chia thành các Nhiệm Kỳ (Terms) đánh số nguyên tăng dần ($T_1, T_2, T_3,...$). Term hoạt động như một chiếc đồng hồ logic phân tán (Logical Clock) giúp hệ thống phát hiện các thông tin lỗi thời từ các Leader cũ.

code(15 dòng)
Sao chép
       [Khởi động]
            |
            v
      +------------+   Election Timeout
      |  Follower  | --------------------+
      +------------+                     |
            ^                            v
            |  Term lớn hơn        +-----------+
            +--------------------- | Candidate |
            |                      +-----------+
            | Nhận Heartbeat             | Nhận đa số phiếu (Quorum)
            |                            v
            |                     +-----------+
            +-------------------- |  Leader   |
                                  +-----------+

Log Replication & Nguyên Tắc Quorum Majority

Khi client gửi một lệnh SET x = 10:

1. Leader ghi lệnh vào log của mình tại vị trí index tiếp theo với nhiệm kỳ hiện tại.
2. Leader gửi RPC AppendEntries tới toàn bộ các Follower.
3. Khi nhận được phản hồi xác nhận từ đa số nút trong cụm (Quorum: $\lfloor N/2 \rfloor + 1$), Leader đánh dấu entry đó là Committed.
4. Leader áp dụng lệnh vào State Machine và trả kết quả thành công về cho client.
5. Trong các nhịp heartbeat kế tiếp, Leader thông báo leaderCommit index để các Follower lần lượt commit theo.

Cấu Trúc RPC AppendEntries

go(8 dòng)
Sao chép
type AppendEntriesArgs struct {
    Term         uint64     // Nhiệm kỳ hiện tại của Leader
    LeaderID     string     // ID của Leader để Follower chuyển hướng client
    PrevLogIndex uint64     // Chỉ mục của entry ngay trước entry mới
    PrevLogTerm  uint64     // Nhiệm kỳ của entry tại PrevLogIndex
    Entries      []LogEntry // Danh sách các entry cần sao chép (rỗng nếu là Heartbeat)
    LeaderCommit uint64     // Chỉ mục commit cao nhất hiện tại của Leader
}

Kịch Bản Phân Mảnh Mạng (Split-Brain & Partition Healing)

Xét một cụm Raft gồm 5 nút: {A, B, C, D, E}. Ban đầu Node A đang là Leader.

code(7 dòng)
Sao chép
Phân vùng 1 (Minority - Thiểu số):
  Node A (Leader) --- Node B

================ RÀO CẢN MẠNG ================

Phân vùng 2 (Majority - Đa số):
  Node C --- Node D --- Node E (Bầu Node C làm Leader mới với Term cao hơn)

• Bên phân vùng thiểu số ({A, B}): Node A vẫn nghĩ mình là Leader và nhận request ghi dữ liệu. Tuy nhiên, Node A chỉ có thể gửi RPC tới Node B (tổng cộng 2/5 nút, không đạt Quorum 3/5). Do đó, các entry này không bao giờ được Commit và bị treo trạng thái chờ.
• Bên phân vùng đa số ({C, D, E}): Ba nút này phát hiện mất heartbeat từ Node A, chuyển sang Candidate và bầu Node C làm Leader ở Term $T+1$. Mọi thao tác ghi ở đây đều đạt 3/5 nút và được Commit bình thường.
• Khi kết nối mạng được hàn gắn: Node A nhận được gói tin AppendEntries từ Node C kèm Term $T+1$. Thấy Term của mình đã lỗi thời, Node A lập tức tự giáng cấp xuống Follower, hủy bỏ toàn bộ các uncommitted log chưa hợp lệ và đồng bộ theo nhật ký chuẩn của Node C.

Hệ thống bảo đảm 100% tính nhất quán dữ liệu mà không cần đến các thuật toán 2PC (Two-Phase Commit) cồng kềnh.