Search code examples
distributed-systemconsensusraft

Does Raft follower store leader ID? If not, how does it redirect requests to leader?


Referring to this table depicted in the Raft paper, I did not find where do followers memorize the leader in any form such as identifier, physical addr, etc. Instead, I only find the leader ID in appendEntries, which, however, seems not to be saved anywhere. enter image description here

Could anyone kindly teach:

  • If, like the table shows, followers do not save info regarding current leader, how do followers redirect the requests sent to them to the leader?

  • If otherwise, how is the leader info saved in followers' side? is it an identifier alike thing or actual address?


Solution

  • By looking at the Golang implementation of Raft, I found the lead ID is actually stored, although I cannot be sure for now is it volatile or persisted on disk. I'll go on trying and see if I could find the place where data persistence takes place.

    type raft struct {
        id uint64
    
        Term uint64
        Vote uint64
        ...
    
        // the leader id
        lead uint64
        ...
    }
    

    Based on the leader ID, follower redirect the request from client to leader in current term, see below:

        case pb.MsgReadIndex:
            if r.lead == None {
                r.logger.Infof("%x no leader at term %d; dropping index reading msg", r.id, r.Term)
                return nil
            }
            m.To = r.lead
            r.send(m)
            ...
    

    The leader ID turns out to be an identifier instead of an actual address, it relies on the application layer that uses Raft library to map the ID to ip address, etc, for example, etcd, which uses Raft, keeps an ID to addr mapping:

    type Member struct {
        // ID is the unique identifier of this Member.
        ID string `json:"id"`
    
        // Name is a human-readable, non-unique identifier of this Member.
        Name string `json:"name"`
    
        // PeerURLs represents the HTTP(S) endpoints this Member uses to
        // participate in etcd's consensus protocol.
        PeerURLs []string `json:"peerURLs"`
    
        // ClientURLs represents the HTTP(S) endpoints on which this Member
        // serves its client-facing APIs.
        ClientURLs []string `json:"clientURLs"`
    }