MIT 6.824分布式 LAB2B：Raft

Lab 2B难度为hard，但是有了之前2A的经历，于我而言，2B的难度倒是远低于2A的难度。2B需要实现的功能就只是log replication。

在写2B的过程中，我还找到了之前2A写的一些bug，说实话，多线程的程序，有些bug真的很难发现，你会发现突然某次运行就有一个raft节点发生了死锁，没有任何响应了，大概率是因为锁设置的太多了，导致某处出现了死锁，同时此写这个lab对于我debug能力的提升也挺大。

完成过程中，又学到了很多写多线程的注意点。

注意：代码中的注释都是我用中式英语写的，大家可能会看不懂。还有就是之前Lab 2A中的部分代码还是有问题的，在此次实验中发现并修改了。

介绍

Lab 2B就是让我们实现log replication，这块功能是和投票、心跳机制紧密关联的，因此我们在实现这部分功能的时候肯定也会适当调整这些代码。

go test -race -run 2B
#这个就是用来进行Lab 2B的测试指令

注意事项

由于实验说明除了在2A处说了注意事项，就没说了，因此这里的注意事项，是我过程中踩的坑。

1、如果进入临界区之前需要同时获取多个锁，那么确保整个代码的其他部分用到这些锁的获取顺序是一致的，不然可能会出现死锁。

举例：需要查看并修改的变量涉及两个互斥锁，mutex1和mutex2。应该确保都是一直的获取顺序，例如先获取mutex1再获取mutex2

A:
mutex1.Lock()
defer mutex1.Unlock()
mutex2.Lock()
defer mutex2.Unlock()
Code...
​
​
​
​
B:
mutex2.Lock()
defer mutex2.Unlock()
mutex1.Lock()
defer mutex1.Unlock()
Code...

如果，goroutine A 先获取mutex1，goroutine B先获取了mutex2，然后就发生了死锁。

一般来说，这个地方知识大部分人都应该知道，但是有时候急了，进行复制粘贴进行代码复用的时候，一不注意就会导致上面的发生。

2、每个goroutine尽量只使用当前协程中的局部变量，若使用rf.nextIndex这种多协程共享的变量，那么该共享变量如果在协程外被改变了，多个协程之间的不确定性地执行，给这个变量带来不具有确定性的值，这大概率会带来bug。因此，goroutine如果需要使用共享变量，应该用一个局部变量将这个时刻的共享变量保存下来使用。

3、在进行RPC调用的时候，不要复用reply变量，每次进行RPC调用时都应该用新创建的reply变量来接受RPC的调用结果，不然在本实验中，你也将接受到一个警告---labgob warning: Decoding into a non-default variable/field %v may not work。

4、每个goroutine需要注意自身是否已经过时，例如：该协程是raft1作为leader发起的，但是过了一会儿raft1就已经不是Leader了，那么此时goroutine就已经过时了，不应该将完成的结果提交上去，而是选择结束例程。亦或是，一个最新的协程先提交了结果，将matchIndex[id]的数值更新为了n，此时过时的协程提交结果，想要将matchIndex[id]的数值更新为n-1就是不合理的。

5、在本实验中，我们使用sendAppendEntreis函数向followers进行log replication时，调用sendAppendEntreis函数可能会失败，因此需要设定失败重调的机制，确保能够成功向followers发出log。

6、在本实验中，可能followers收到的ae包，里面的Log为index：a-b，但是自身的已有的log的index：c

c>b，那么这种情况有以下几种可能：（1）这个ae包由于网络延迟而比后发的ae包都迟了，导致这个ae包已经过时了；（2）由于leader同时收到大量command，由于大量的Log replication协程是并发进行，可能负责index比较小的那个协程执行分配到的cpu资源很少，导致一直没执行，从而导致发出的ae包时，这个ae包已经过时了；（3）这个follower本身log中包含大量uncommit的无效log，因此需要把那些无效Log记录给删掉。

本次实验内容

1、继续完善Raft结构体内的信息，并设计Log的结构体。

2、实现Start()函数

3、继续完善AppendEntries()函数

4、继续完善heartBeats()函数

5、继续完善ticker()函数

6、继续完善Make()函数

代码阶段

继续完善Raft结构体，设计Log的结构体

首先，实验说明中可以知道raft节点对于每一个commit的log都需要把该log放到applyCh管道中，而这个管道在raft节点创建的时候作为Make函数中的参数给予的，因此仅需在结构体中添加一个变量来保存管道即可。

log结构体的设计，里面肯定要能保存Command，同时还需要保存这个log对应的index和term。同时Command的数据类型，可以看到ApplyMsg结构体中指定Command为Interface{}，我们也就和它一样即可。

代码如下所示:

type LogEntry struct {
    Index   int
    Term    int
    Command interface{}
}
​
type Raft struct {
    mu        sync.Mutex          // Lock to protect shared access to this peer's state
    peers     []*labrpc.ClientEnd // RPC end points of all peers
    persister *Persister          // Object to hold this peer's persisted state
    me        int                 // this peer's index into peers[]
    dead      int32               // set by Kill()
​
    // Your data here (2A, 2B, 2C).
    // Look at the paper's Figure 2 for a description of what
    // state a Raft server must maintain.
    peerNum int
​
    // persistent state
    currentTerm int
    voteFor     int
    log         []LogEntry
​
    // volatile state
    commitIndex int
    lastApplied int
    // lastHeardTime time.Time
    state        string
    lastLogIndex int
    lastLogTerm  int
​
    // send each commited command to applyCh
    applyCh chan ApplyMsg
​
    // Candidate synchronize election with condition variable
    mesMutex    sync.Mutex // used to lock variable opSelect
    messageCond *sync.Cond
​
    // opSelect == 1 -> start election, opSelect == -1 -> stay still, opSelect == 2 -> be a leader, opSelect == 3 -> election timeout
    opSelect int
​
    // special state for leader
    nextIndex  []int
    matchIndex []int
}

实现Start()函数

Start()作为一个接口提供给外界，将指令发送给raft节点，请求其进行执行。下面讲解这个函数的执行流程：

1. 函数收到一个command，首先判断自身是否为Leader，若不是则返回，若是继续。

2. leader收到一个command后，需要将该命令保存到本地的log中，并更新matchIndex、nextIndex、lastLogIndex、lastLogTerm等变量。

3. 调用多个goroutine来并发地给其余follower发起Log replication请求。在每个goroutine中，注意查看注意事项中的第二条。例如：本实验中，负责log replication的goroutine中，将rf.nextIndex[id]这个共享变量的值赋给了局部变量nextIndex；想要获取发起goroutine时rf.currentTerm的值，就去查看args.Term值即可。

4. 负责id=n号follower节点的log replication的goroutine中，首先需要检查该n号raft节点的nextIndex，将nextIndex和index进行比较，index为最新来的Log的索引值，如果两者存在差值表明，n号Raft节点和leader之间差了不止index号这么一个Log值，我们需要将nextIndex+1~index之间的Log也需要打包到log数组中一块发送给follower。后续，leader将nextIndex指定的Index号的log包也添加到Log数组中。

5. 这里leader将nextIndex位置的log继续打包到log数组中，然后通过sendAppendEntries RPC调用将log数组发送给Follower。该RPC调用返回值为true则表明Log同步成功，后续更新matchIndex[id]即可，更新的时候，注意查看注意事项中的第四条，协程想要matchIndex[id]更新为n，但是发现matchIndex[id]的数值大于n，这则表明该协程已经过时了，则不更新matchIndex[id]的值了。

若该RPC调用返回值为false，那么就要分情况来进行处理了：

reply.Term > args.Term：则表明该goroutine已经过时了，需要停止该goroutine并检查raft节点是否及时更新了Term值，若没有则将rf.currentTerm更新为reply.Term。

reply.Term <= args.Term：则表明，follower发现preLogTerm和preLogIndex并不匹配，需要leader发送更早的log。这种情况下，leader可以逐步一个个将前面的log加进去和follower进行确认是否匹配，但是一个个加log并询问follower的效率太低了，应该利用reply中的follower的term值，来加速定位，因为Follower中的log的term值一定都不会大于follower的term值，所以那些term> follower.term的log必然是follower缺失的。后续再尝试一个个加更早的log。直到follower返回true，表明找到了两者log相同的地方了，并将后续的log都同步上了。

1. leader完成了给一个follower的同步后，进行matchIndex检查是否又有新的Log已经同步到大多数的节点上，这个检查是通过收集各个节点的matchIndex，对matchIndex的出现次数进行一个计数形成一个key-val的数组，key为matchIndex，value为处于这个matchIndex的节点数量，这个数组按照key从高到低的排序，然后遍历数组进行累加value的值，直到value累加的值刚好超过raft节点的半数，则这个key值即为此时的半数节点都已经同步了的最新的log的index值。

2. 将这个index值和commitIndex进行比较，若大于则表明有新的log同步到半数节点上了，可以进行提交，更新commitIndex值，并将提交的指令发送到applyCh管道中以及更新lastApplied变量的值。

注意：leader每次更新commitIndex并提交执行新的log的时候，并不会立刻通知节点去提交，为了减轻网络流量压力，这个通知可以让周期的heartbeat去顺带通知。这里heartbeat通知follower更新commitIndex的细节将放在heartbeat函数那儿讲解。

代码如下：

//
// the service using Raft (e.g. a k/v server) wants to start
// agreement on the next command to be appended to Raft's log. if this
// server isn't the leader, returns false. otherwise start the
// agreement and return immediately. there is no guarantee that this
// command will ever be committed to the Raft log, since the leader
// may fail or lose an election. even if the Raft instance has been killed,
// this function should return gracefully.
//
// the first return value is the index that the command will appear at
// if it's ever committed. the second return value is the current
// term. the third return value is true if this server believes it is
// the leader.
//
func (rf *Raft) Start(command interface{}) (int, int, bool) {
    index := -1
    term := -1
    isLeader := true
    // Your code here (2B).
    _, isLeader = rf.GetState()
    if !isLeader {
        return index, term, isLeader
    }
    rf.mu.Lock()
    defer rf.mu.Unlock()
    rf.lastLogTerm = rf.currentTerm
    rf.lastLogIndex = rf.nextIndex[rf.me]
    index = rf.nextIndex[rf.me]
    term = rf.lastLogTerm
    var peerNum = rf.peerNum
    var entry = LogEntry{Index: index, Term: term, Command: command}
    rf.log = append(rf.log, entry)
    fmt.Printf("%v              leader%d receive a command, index:%d term:%d\n", time.Now(), rf.me, index, term)
    rf.matchIndex[rf.me] = index
    rf.nextIndex[rf.me] = index + 1
​
    for i := 0; i < peerNum; i++ {
        if i == rf.me {
            continue
        }
        go func(id int, nextIndex int) {
            var args = &AppendEntriesArgs{}
            rf.mu.Lock()
            args.Entries = make([]LogEntry, 0)
            if nextIndex < index {
                for j := nextIndex + 1; j <= index; j++ {
                    args.Entries = append(args.Entries, rf.log[j])
                }
            }
            args.Term = rf.currentTerm
            args.LeaderId = rf.me
            // we update the nextIndex array at first time, even if the follower hasn't received the msg.
            if index+1 > rf.nextIndex[id] {
                rf.nextIndex[id] = index + 1
            }
            rf.mu.Unlock()
​
            for {
                var reply = &AppendEntriesReply{}
                rf.mu.Lock()
                args.PrevLogIndex = rf.log[nextIndex-1].Index
                args.PrevLogTerm = rf.log[nextIndex-1].Term
                args.Entries = rf.log[nextIndex : index+1]
                // args.Entries = append([]LogEntry{rf.log[nextIndex]}, args.Entries...)
                rf.mu.Unlock()
                for {
                    // if sendAE failed, retry util success
                    if rf.sendAppendEntries(id, args, reply) {
                        break
                    }
                }
                rf.mu.Lock()
                if reply.Term > args.Term {
                    if reply.Term > rf.currentTerm {
                        rf.currentTerm = reply.Term
                        rf.state = "follower"
                        rf.voteFor = -1
                        fmt.Printf("%v raft%d find a higher term, turn back to follower, term:%d\n", time.Now(), rf.me, rf.currentTerm)
                        rf.mu.Unlock()
                        break
                    }
                    fmt.Printf("%v goroutine (term:%d, raft%d send log to raft%d) is out of date. Stop the goroutine.\n", time.Now(), args.Term, rf.me, id)
                    rf.mu.Unlock()
                    break
                }
                if !reply.Success {
                    if rf.log[nextIndex-1].Term > reply.Term {
                        for rf.log[nextIndex-1].Term > reply.Term {
                            nextIndex--
                        }
                    } else {
                        nextIndex--
                    }
                    // nextIndex--
                    if nextIndex == 0 {
                        fmt.Printf("Error:leader%d send log to raft%d, length:%d \n", rf.me, id, len(args.Entries))
                        rf.mu.Unlock()
                        break
                    }
                    rf.mu.Unlock()
                } else {
                    fmt.Printf("%v              leader%d send log from %d to %d to raft%d\n", time.Now(), rf.me, nextIndex, index, id)
                    if rf.matchIndex[id] < index {
                        rf.matchIndex[id] = index
                    }
                    // we need to check if most of the raft nodes have reach a agreement.
                    var mp = make(map[int]int)
                    for _, val := range rf.matchIndex {
                        mp[val]++
                    }
                    var tempArray = make([]num2num, 0)
                    for k, v := range mp {
                        tempArray = append(tempArray, num2num{key: k, val: v})
                    }
                    sort.Slice(tempArray, func(i, j int) bool {
                        return tempArray[i].key > tempArray[j].key
                    })
                    var voteAddNum = 0
                    for j := 0; j < len(tempArray); j++ {
                        if tempArray[j].val+voteAddNum >= (rf.peerNum/2)+1 {
                            if rf.commitIndex < tempArray[j].key {
                                fmt.Printf("%v              %d nodes have received %d mes, leader%d update commitIndex from %d to %d\n", time.Now(), tempArray[j].val+voteAddNum, tempArray[j].key, rf.me, rf.commitIndex, tempArray[j].key)
                                rf.commitIndex = tempArray[j].key
                                for rf.lastApplied < rf.commitIndex {
                                    rf.lastApplied++
                                    var applyMsg = ApplyMsg{}
                                    applyMsg.Command = rf.log[rf.lastApplied].Command
                                    applyMsg.CommandIndex = rf.log[rf.lastApplied].Index
                                    applyMsg.CommandValid = true
                                    rf.applyCh <- applyMsg
                                    fmt.Printf("%v              leader%d insert the msg%d into applyCh\n", time.Now(), rf.me, rf.lastApplied)
                                }
                                break
                            }
                        }
                        voteAddNum += tempArray[j].val
                    }
​
                    rf.mu.Unlock()
                    break
                }
​
                time.Sleep(10 * time.Millisecond)
            }
        }(i, rf.nextIndex[i])
    }
    return index, term, isLeader
}

继续完善AppendEntries()函数

由于实验2B中，AE RPC调用不再仅仅是heartbeat了，因此，我在这里将log replication和heartbeat这两者进行了区分处理，heartbeat调用AppendEntries时，传来的参数中是没有log数组的，而如果是进行log replication那么必然会发送来Log数组，因此我将此作为区分点。

以下是这个函数的处理流程：

Term的比较以及对应的处理，在lab2A中已经讲述，此处不赘述。

若args.Entries数组为nil，那么表明为heartbeat调用的；反之，表明为log replication调用的。

heartbeat调用的AppendEntreis时：

1. 如果args.LeaderCommit > rf.commitIndex，则更新rf.commitIndex = args.LeaderComiit，并进入步骤2。反之就返回true即可。

2. 更新了rf.commitIndex表明，有新的log可以提交并执行了，随后把那些log发送到applyCh管道中，并更新lastApplied变量的值。

Log replication调用的AppendEntreis时：

log同步应该在双方Log一致的index点开始，因此这里着重点在于回馈给leader一致的index在哪儿。

当然里面还有很多特殊情况需要考虑。

1. follower需要检查发送来的ae包是否满足本节点的缺失情况，也就是检查args.PreLogIndex和rf.lastLogIndex。

2. 如果args.PreLogIndex > rf.lastLogIndex表明肯定不满足本节点的缺失情况，则返回false；反之进入步骤3

3. 来到这儿表明args.PreLogIndex <= rf.lastLogIndex，这依旧不能确定这个ae包是满足本节点的缺失情况的，可能本节点存在部分无效的Log，举例来说：一个leader加了好多log，但是断开了连接这些新加的log都没有来得及发送给任何一个节点，后续重连回来就成为follower了，那么这些独自拥有的的log就是无效Log。

4. raft算法的特点之一是，如果两个Log的index和term都是一样的，那么这两个log必然是一致的。因此Follower仅需判断args.PrevLogTerm == rf.log[args.PreLogIndex]是否成立，如果成立表明，在args.PrevLogIndex这里以及之前的Log都是同步的了。否则，就是args.PreLogIndex < rf.lastLogIndex，但是这个索引值为args.PreLogIndex处的log，两个节点的log依旧不一致，需要返回false，让leader继续往前找到一致的index。

注意：follower发现发来的这个ae包中的log的PrevLogIndex和PrevLogTerm都是符合条件的，但是依旧不一定就要同步上来。我们需要注意部分ae是过时的，例如：1号ae包负责将follower同步到index=n处的Log；2号ae包负责而将follower同步到index=n+1处的log。但是1号ae比2号还迟，2号ae包已经将各个Follower的log同步到了index=n+1处，当过时的1号ae包被follower接受到时，follower依旧按照包中指示同步到index=n处，那么同步进度就倒退了，将会引发bug。因此follower还需要检测这个ae是否过时。

        5. 到这里，表明这个ae包是合法的，同步的开始Log处，双方也都是一致的，但是需要判断这个ae是否是过时的。follower仅需检测，发来的ae包中，args.Entreis中最新的log，本节点中有没有，若有的话，表明无需同步，这个包是过时的了。若没有则进入下一步进行同步。

        6. 更新本地的rf.log ，rf.lastLogIndex，rf.lastLogTerm等变量。

代码如下：

func (rf *Raft) AppendEntries(args *AppendEntriesArgs, reply *AppendEntriesReply) {
    rf.mu.Lock()
    defer rf.mu.Unlock()
    reply.Term = rf.currentTerm
    if args.Term < rf.currentTerm {
        reply.Success = false
    } else {
        // fmt.Printf("raft%d receive ae from leader%d\n", rf.me, args.LeaderId)
        if args.Entries == nil {
            // if the args.Entries is empty, it means that the ae message is a heartbeat message.
            if args.LeaderCommit > rf.commitIndex {
                fmt.Printf("%v              raft%d update commitIndex from %d to %d\n", time.Now(), rf.me, rf.commitIndex, args.LeaderCommit)
                rf.commitIndex = args.LeaderCommit
                for rf.lastApplied < rf.commitIndex {
                    rf.lastApplied++
                    var applyMsg = ApplyMsg{}
                    applyMsg.Command = rf.log[rf.lastApplied].Command
                    applyMsg.CommandIndex = rf.log[rf.lastApplied].Index
                    applyMsg.CommandValid = true
                    rf.applyCh <- applyMsg
                    fmt.Printf("%v              raft%d insert the msg%d into applyCh\n", time.Now(), rf.me, rf.lastApplied)
                }
            }
            reply.Success = true
        } else {
            // if the args.Entries is not empty, it means that we should update our entries to be aligned with leader's.
            if args.PrevLogIndex <= rf.lastLogIndex {
                if args.PrevLogTerm == rf.log[args.PrevLogIndex].Term {
                    // Notice!!
                    // we need to consider a special situation: followers may receive a older log replication request, and followers should do nothing at that time
                    // so followers should ignore those out-of-date log replication requests or followers will choose to synchronized and delete lastest logs
                    var length = len(args.Entries)
                    var index = args.PrevLogIndex + length
                    reply.Success = true
                    if index < rf.lastLogIndex {
                        // check if the ae is out-of-date
                        if args.Entries[length-1].Term == rf.log[index].Term {
                            fmt.Printf("%v              raft%d receive a out-of-date ae and do nothing. prevLogIndex:%d, length:%d from leader%d\n", time.Now(), rf.me, args.PrevLogIndex, length, args.LeaderId)
                            return
                        }
                    }
                    fmt.Printf("%v              raft%d receive prevLogIndex:%d, length:%d from leader%d\n", time.Now(), rf.me, args.PrevLogIndex, length, args.LeaderId)
                    rf.log = rf.log[:args.PrevLogIndex+1]
                    rf.log = append(rf.log, args.Entries...)
                    // fmt.Printf("%v               raft%d log:%v\n", time.Now(), rf.me, rf.log)
                    var logLength = len(rf.log)
                    rf.lastLogIndex = rf.log[logLength-1].Index
                    rf.lastLogTerm = rf.log[logLength-1].Term
​
                }
            } else {
                reply.Success = false
            }
        }
​
        if rf.currentTerm < args.Term {
            fmt.Printf("%v raft%d update term from %d to %d\n", time.Now(), rf.me, rf.currentTerm, args.Term)
        }
        rf.currentTerm = args.Term
        rf.state = "follower"
        rf.changeOpSelect(-1)
        rf.messageCond.Broadcast()
    }
}

继续完善heartBeats()函数

这里给heartBeats函数多加的一个功能就是通知follower更新commitIndex。

注意：我们需要考虑部分节点尚未同步log，若leader无条件地向那些follower通知自身的commitIndex更新了，要求它们也同步更新，将会导致混乱。因此leader应该需要根据follower的情况来进行选择性的通知。

Leader应该通知那些同步的进度超过commitIndex的节点，Leader处有commitIndex这个数组记录了各个follower的同步进度，因此可以利用这个数组来进行判断即可。

本实验中，若leader要通知节点进行更新commitIndex，仅需在发给follower的ae包中赋值args.LeaderCommit = rf.commitIndex，随后follower就能收到最新的commitIndex。

若leader发现节点的同步进度不够，并不通知节点进行更新commitIndex，那么在发给follower的ae包中不赋值args.LeaderCommit即可，这个参数的默认值为0，并不会对follower的commitIndex造成任何影响。

由于代码变动较小，仅放出更新的地方：

go func(index int) {
                rf.mu.Lock()
                var args AppendEntriesArgs
                args.LeaderId = rf.me
                args.Term = rf.currentTerm
                if rf.matchIndex[index] >= rf.commitIndex {
                    args.LeaderCommit = rf.commitIndex
                }
                rf.mu.Unlock()
                ...
            }(index)

继续完善ticker()函数

在本实验中，需要进行log replication，Leader需要使用nextIndex和matchIndex这两个变量，因此每个raft节点成为leader后都需要对这两个变量进行初始化。

按照paper中的说法，leader开始需要将matchIndex数组全部初始化为0，nextIndex数组的初始化则按照自身的nextIndex初始化。为什么这么初始化，去看paper即可，此处不赘述。

由于代码变动较小，仅放出更新的地方：

if rf.opSelect != -1 && rf.opSelect != 4 && term == rf.currentTerm && times == currentTermTimes {
                            // suceess means the node successfully becomes a leader
                            rf.opSelect = 2
                            rf.state = "leader"
                            var length = len(rf.log)
                            // reinitialize these two arrays after election
                            for i := 0; i < rf.peerNum; i++ {
                                rf.nextIndex[i] = rf.log[length-1].Index + 1
                                rf.matchIndex[i] = 0
                            }
                            fmt.Println("leader's nextIndex array:", rf.nextIndex)
                            fmt.Println("leader's matchIndex array:", rf.matchIndex)
                            rf.messageCond.Broadcast()
                        }

继续完善Make()函数

本实验中，在raft结构体中多了applyCh这个管道，以及需要使用nextIndex和matchIndex这两个切片，因此在raft节点初始化时，也需要对这些变量初始化。

注意：实验说明中提到，index应当从1开始，为了index的值和log数组的索引值对应起来，我将log数组的0号索引位用一个index和term均为0的log来占用了，这样的做了以后，index为1的log就存放在log[index]处。而非log[index-1]处。同时这个index和term均为0的log作为数组的头部，在log数组遍历时可以以此来判断是否到了数组的头部。

applyCh的值直接从Make函数中的参数直接拿来赋值即可。

nextIndex和matchIndex由于都是切片需要用make进行初始化，并且这些切片的长度应该和raft节点数一样。

由于代码变动较小，仅放出更新的地方：

rf.log = make([]LogEntry, 1)
rf.log[0].Index = 0
rf.log[0].Term = 0
rf.applyCh = applyCh
rf.nextIndex = make([]int, rf.peerNum)
rf.matchIndex = make([]int, rf.peerNum)

实验结果图

由于实验过程中插桩了大量调试用的fmt.Printf指令，我最后也懒得把那些指令给删除了，因此图片中就我截取了最后一行的成功输出。