lec 4: Raft

[moyuanhuang]

• [x] 2A: Implement leader election and heartbeats 这部分的试验主要实现3个raft.go中的函数，当然还需要看懂理解其他几个类的作用。另外，根据这门课助教的提醒，一定要严格遵守论文中Figure.2的实现细节。（我真的就是踩了其中的几个坑导致写了整整两天啊摔）

• config.go 除了raft.go之外最重要的文件，相当于是client(tester)与Raft的接口。其中config.net没有使用golang中自带的rpc package，而是自己实现了一个labrpc包，为了增加模拟network failure的功能以便测试Raft。endnames是储存了Raft server之间的“代号”，每次server i重启的时候都会刷新相应的endnames[i]数组。这个地方不明白没关系，可以暂时跳过。 这里有一个困扰我很久的问题就是clientEnd变量的角色。一开始我以为是向Raft发送Entry的app client，导致代码很多地方都讲不通。后来才明白这里的Client是针对Raft内部server来讲的，也就是每个client代表的都是一个Raft server，为了避免混淆，后面都把这些内部的server叫做peers。

• persist.go 用来持久化每个server的状态，包括内部状态以及数据，在之后的试验中还会用到这里的snapshot函数。

• util.go 这里提供了一个debug函数，可以将Debug设为1来打印程序中所有用DPrintf打印的输出。之后将debug设置成0就可以直接看见测试结果啦（如果用fmt.Printf就要一个一个删掉），强迫症患者福音。

---

1. Raft成员 基本上就是根据Figure.2 State那一栏中的定义了。我认为需要注意的成员是votedFor int，这个变量记录了当前term的leader票投给了谁，我将它初始化为-1代表本轮还未投票。一旦voteFor被赋上了非负值，说明这个peer已经投过票。在paper中有这么一句不起眼的话

Each server will vote for at most one candidate in a given term ...

因此，在term改变之前，只要voteFor非负，peer会拒绝其他所有的RequestVote RPC。除此之外，我还加上了

state string  // current state of itself: follower, candidate or leader
hasHeartbeat bool  // used for checking heartbeat

2. constructor(Make()) 初始化一个新的raft peer。在构造器中除了对每个成员进行初始化之外，更重要的一件事就是启动一个新的goroutine来控制自己的state。对于在不同状态下的peer有不同的转换逻辑，在Figure.2的Rules for servers中给出。这里的难点在于如何在收到heartbeat后reset electionTimeOut。根据lab指导，有同学会使用time.Sleep(electionTimeOut)。我认为这样是不准确的：相当于只要Sleep的时间内收到一次heartbeat，goroutine醒来后就会重置electionTimeOut，实际上是延长了electionTimeOut时间。我的方法在这里，大概就是每隔time.Sleep(BroadcastInv)来检查heartbeat。

3. RequestVote RPC

4. AppendEntries RPC

[moyuanhuang]

迷思1：

Figure.2 rules for server: "for All servers: if RPC request or response contains term T > currentTerm: set currentTerm = T, convert to follower." Consider this scenario:

1. L1, F1, F2正常通讯under Term 1
2. F1网络出了问题，没收到L1的heartbeat导致timeout，自己变成Candidate。紧接着F1网络恢复，向其它peer发送RequestVote RPC，注意此时RPC中的Term已变为2。
3. F2收到Term 为 2的RequestVote，根据规则，清空votedFor，把Term2的票投给F1。
4. F1收到F2的票，加上自己的票，过了半数，因此变成Term2 Leader。
5. L1收到F2的heartbeat response后检查Term发现比自己的大，退为follower。

综上，本来只是一个Follower(F2)自己的网络出了问题，最后却导致Leader改变，Term更替。这样岂不是很划不来？？Term1的Leader好冤啊。而且如果Follower网络问题频繁的话，不是总得换leader？

[moyuanhuang]

• [x] Lab 2B: implement Start() and complete AppendEntries RPC 这部分要增加Raft接收客服端发来Log的功能，这个接口就是func (rf *raft) Start(command interface{}) int, int, bool。其中每个返回值用来保存什么信息在源代码的注释中已经做出解释。除了接收Log，最重要的就是每个Peer可以通过Leader对日志达成共识，以达到最后Log committed的目的。

config向Raft输入command的两种方法

sync.Cond条件变量需要在哪里使用

AppendEntries RPC

• 何时返回false
• 如何更新本地的rf.logs
• 如何更新rf.commitIndex
• 更新term