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.
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?
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"`
}