一.实验目标
要完成日志复制部分，也就是要修改appendAntries和requestvote部分
二.思路
requestvote投true的话，有两个条件：1.日志是最新的，2.当前term是最大的。如果有一个term大于leader的分区机器进来的话，先提升所有机器term，然后再选举，这是不稳定的，所有有了prevote优化，就是分区后candidate先联系别的机器看是否有可能当选leader，如果不可能的话，就不自增term，也就没可能分区时独自自增了。下面的是requestvote部分代码：
分析如下，也就是为了让日志都是leader流向follower进行的选举约束：那些commit的log一定在leader上，因为commit和requestvote都要满足大多数原则，所以有重叠，这样就一定存在可选leader.
func (rf *Raft) RequestVote(args *RequestVoteArgs, reply *RequestVoteReply) {
// Your code here (2A, 2B).
log.Println("Rpc requestVote start ", rf.me)
rf.mu.Lock()
log.Println("Rpc get lock", rf.me)
defer rf.mu.Unlock()
reply.Vote_Granted = false
if rf.CurrentTerm > args.Candidate_Curr_Term || (rf.CurrentTerm == args.Candidate_Curr_Term && rf.VoteFor != -1 && rf.VoteFor != args.Candidate_Id) {
reply.Current_Term = rf.CurrentTerm
reply.Vote_Granted = false
log.Println(args.Candidate_Id, " vote grand fail", rf.me)
return
}
if args.Candidate_Curr_Term > rf.CurrentTerm {
log.Println("request is higer!!!!")
rf.ToFollower()
rf.VoteFor = -1
rf.CurrentTerm = args.Candidate_Curr_Term
}
// election limitation
if args.Last_Log_Term < rf.Log_Array[len(rf.Log_Array)-1].Log_Term {
reply.Current_Term = rf.CurrentTerm
reply.Vote_Granted = false
log.Println(args.Candidate_Id, " vote grand fail the log term not new", rf.me)
return
}
if args.Last_Log_Term == rf.Log_Array[len(rf.Log_Array)-1].Log_Term && args.Last_Log_Index < len(rf.Log_Array)-1 {
reply.Current_Term = rf.CurrentTerm
reply.Vote_Granted = false
log.Println(args.Candidate_Id, " vote grand fail the log length is small", rf.me)
return
}
// 两个条件均满足投true
rf.VoteFor = args.Candidate_Id
reply.Current_Term = rf.CurrentTerm
log.Println(args.Candidate_Id, " vote grand ", rf.me)
rf.ResetElection()
reply.Vote_Granted = true
// TODO: term is used for the candidate to update itself
}关于空心跳和带有日志的心跳，这里参考了谭神的blog，用了replicator协程来单独处理每个peer的log heartbeat。这样确实是大量减少了思维负担，神来之笔！
for peer := range rf.peers {
rf.Next_Idx[peer] = 1
rf.Match_Idx[peer] = 0
if peer != rf.me {
rf.ReplicatorCond[peer] = sync.NewCond(&sync.Mutex{})
go rf.replicator(peer)
}
}
func (rf *Raft) replicator(peer int) {
rf.ReplicatorCond[peer].L.Lock()
defer rf.ReplicatorCond[peer].L.Unlock()
for !rf.killed() {
// if there is no need to replicate entries for this peer, just release CPU and wait other goroutine's signal if service adds new Command
// if this peer needs replicating entries, this goroutine will call replicateOneRound(peer) multiple times until this peer catches up, and then wait
for !rf.NeedReplicating(peer) {
rf.ReplicatorCond[peer].Wait()
}
rf.replicateOneRound(peer)
}
}如果是log heartbeat的话，就向replicator发一个signal，然后执行一轮心跳复制，这样完美解决了一次复制不完的问题！
然后就是append部分也就是日志复制最主要的逻辑所在。
func (rf *Raft) AppendEntries(args *AppendArgs, reply *AppendReply) {
rf.mu.Lock()
reply.PrevLogIndex = args.PrevLogIndex
log.Println("append ", rf.me)
defer rf.mu.Unlock()
if args.Leader_Term < rf.CurrentTerm {
reply.Term = rf.CurrentTerm
reply.Success = false
return
}
if args.Leader_Term > rf.CurrentTerm {
rf.CurrentTerm, rf.VoteFor = args.Leader_Term, -1
}
rf.ToFollower()
// log.Println("append success", rf.me, " ", time.Now())
rf.ResetElection()
//日志不match,删除prevlogIndex及其以后的log, 并返回false
if args.PrevLogIndex != 0 {
if args.PrevLogIndex >= len(rf.Log_Array) || rf.Log_Array[args.PrevLogIndex].Log_Term != args.PrevLogTerm {
reply.Success = false
reply.Term = args.Leader_Term
// DPrintf("the follower{%d} log from {%v} to {%v} ", rf.me, rf.Log_Array, rf.Log_Array[:args.PrevLogIndex])
if args.PrevLogIndex < len(rf.Log_Array) {
rf.Log_Array = rf.Log_Array[:args.PrevLogIndex]
}
return
}
} else {
DPrintf("prevlog_idx = 0")
}
// 从PrevLogIndex + 1也就是next_id开始追加存储
// 检查是否需要截断添加，防止rpc乱序到达，截断
if !rf.checkMyLog(args.PrevLogIndex, args.Entries) {
rf.Log_Array = rf.Log_Array[:args.PrevLogIndex+1]
rf.Log_Array = append(rf.Log_Array, args.Entries...)
} else {
DPrintf("the log before will cut the log, and branch here")
}
DPrintf("the follower{%d} log is success log{%v}............", rf.me, rf.Log_Array)
// 设置本地commit为最新日志和leader_commit中较小的一个
if rf.Committed_Idx < args.Leader_Commit {
rf.Committed_Idx = int(math.Min(float64(args.Leader_Commit), float64(len(rf.Log_Array)-1)))
rf.ApplyCond.Signal()
DPrintf("Node{%v} commid{%v} change and notify", rf.me, rf.Committed_Idx)
}
//心跳内容
rf.CurrentTerm = args.Leader_Term
reply.Success = true
//TODO:2,3,4,5 in the paper
}如果日志不匹配的话，就删除后面的日志，然后下一次发生日志就是前一个term的最后一条日志，直到pre_log 为 0。如果匹配的话，不能阶段，因为考虑到rpc乱序到达。如果log长的先到，log短的后到，就截断了，所以多了一步检查。
再append rpc回复处理中也要对rpc乱序做个处理，sequence number就用pre_log来判断，用中位数来做commit_idx，如果变大的话，通知applier线程。感觉while + wait很适合用来做背景线程（协程），处理一些特殊的任务，Applier，和replicator都用上，这也是最大的收获。
func (rf *Raft) processAppendReply(peer int, args AppendArgs, reply AppendReply) {
if reply.PrevLogIndex != rf.Next_Idx[peer]-1 {
log.Printf("rpc order delay")
return
}
if !reply.Success && reply.Term == args.Leader_Term {
//日志不一致失败，减少next_id重试
rf.Next_Idx[peer] = rf.GetIdxPreTerm(rf.Next_Idx[peer] - 1)
log.Printf("Node{%v}'s next_idx become{%v}", rf.me, rf.Next_Idx[peer])
return
}
//发现更大term的candidate, 转变为follwer
if !reply.Success && reply.Term > args.Leader_Term {
log.Println("find the leadr and change state to follower")
rf.ToFollower()
rf.CurrentTerm, rf.VoteFor = reply.Term, -1
return
}
if !reply.Success && reply.Term < args.Leader_Term {
log.Fatalf("reply term smaller")
}
if reply.Success {
log.Printf("Leader Node{%v} receive the Node{%v} append success next_id{%v} log_len{%v}, add{%v}", rf.me, peer, rf.Next_Idx[peer], len(rf.Log_Array), len(args.Entries))
// update next_id and math_id
// 防止两个rpc同时到达乱序
rf.Next_Idx[peer] += len(args.Entries)
rf.Match_Idx[peer] = rf.Next_Idx[peer] - 1
//取match_idx的中位数来做commit_idx,因为满足一半peers已经commit了
DPrintf("match_array{%v}}", rf.Match_Idx)
matchIdx := make([]int, 0)
for i := 0; i < len(rf.peers); i++ {
if rf.me != i {
matchIdx = append(matchIdx, rf.Match_Idx[i])
}
}
matchIdx = append(matchIdx, len(rf.Log_Array)-1)
sort.Ints(matchIdx)
commit_idx := matchIdx[(len(matchIdx))/2]
DPrintf("match_array{%v} and commit_idx{%v}", rf.Match_Idx, commit_idx)
if commit_idx > rf.Committed_Idx {
DPrintf("Leader Node{%v} commit increase from{%v} to {%v} and signal", rf.me, rf.Committed_Idx, commit_idx)
rf.Committed_Idx = commit_idx
//通知applier协程
rf.ApplyCond.Signal()
}
}
}然后就是applier协程了
func (rf *Raft) Applier() {
for !rf.killed() {
rf.mu.Lock()
for rf.Last_Applied_Idx >= rf.Committed_Idx || len(rf.Log_Array) <= rf.Committed_Idx {
rf.ApplyCond.Wait()
DPrintf("Node{%v}, last_applied{%v}, commited_idx{%v}", rf.me, rf.Last_Applied_Idx, rf.Committed_Idx)
rf.Committed_Idx = int(math.Min(float64(rf.Committed_Idx), float64(len(rf.Log_Array)-1)))
DPrintf("{log len{%d}, commit_id{%d}}", len(rf.Log_Array), rf.Committed_Idx)
}
DPrintf("Node{%d}commit_idx{%d} last_applied_idx{%d} log{%v}, logtoapply{%v}", rf.me, rf.Committed_Idx, rf.Last_Applied_Idx, rf.Log_Array, rf.Log_Array[rf.Last_Applied_Idx+1:rf.Committed_Idx+1])
entries := make([]LogEntry, rf.Committed_Idx-rf.Last_Applied_Idx)
copy(entries, rf.Log_Array[rf.Last_Applied_Idx+1:rf.Committed_Idx+1])
DPrintf("Node{%v} enries{%v}", rf.me, entries)
// rf.mu.Unlock()
for _, entry := range entries {
rf.ApplyChan <- ApplyMsg{
CommandValid: true,
Command: entry.Command,
CommandIndex: entry.Index,
}
}
// rf.mu.Lock()
DPrintf("{Node %v} applies entries %v-%v in term %v", rf.me, rf.Last_Applied_Idx, rf.Committed_Idx, rf.CurrentTerm)
rf.Last_Applied_Idx = int(math.Max(float64(rf.Last_Applied_Idx), float64(rf.Committed_Idx)))
rf.mu.Unlock()
}
}applier协程这里是有个bug的，lock,unlock然后就暴露了中间态，不一致了，然后last_apply被下一步的commit先更新了，然后下一步就卡住了。。
还学到了这样打log Node{%v} 这样看的就很清楚有个括号。
测了500次，应该行了
1241
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
