2c简介
简单的说，raft需要将currentTerm、voteFor、entries(当前的所有日志)保存到硬盘进行持久化存储。
保存的方法：在变量改变时，利用persist()中的gob将变量序列化，存储在persister结构体中。（实验不需要真正保存在硬盘上，用persister结构体代替。）
读取的方法：在服务器重启时，利用readPersist()读取保存的序列化参数，并解码成对应变量输入raft中。
test 2c 报错的主要原因是2b、2a的问题，总结下通过c找出的问题。
2b、2a问题
1.在leader更新follower服务器的日志时，如果更新成功，则修改nextIndex[server]、matchIndex[server]。
修改matchIndex时：
rf.nextIndex[i] = len(rf.entries) //?即使错了还能回滚
rf.matchIndex[i] = len(rf.entries) - 1 //错误
rf.matchIndex[i] = rf.nextIndex[i] - 1 //错误
rf.matchIndex[i] = args.PrevLogIndex + len(args.Entries)
有可能在appendEntries()后，客户往raft中加入了若干command，导致日志长度发生变化。计算matchIndex时，使用了错误的日志长度会导致以下提交错误。
2.leader更新follower日志成功时，commitIndex应该为（大多数）比当前commitIndex大的matchIndex中最小的一个，而不是每次提交成功后commitIndex++
如果存在N > commitIndex(本地待提交日志的索引)，majority(matchIndex[i]>=N)(如果参与者大多数的最新日志的索引大于N)，并且这些参与者索引为N的日志的任期也等于leader的当前任期:commitIndex =N(leader的待提交的日志索引设置为N)(5.2和5.4节)。
简单的说，commitIndex应该为matchIndex[]排序后的中位数，前提是这个中位数大于当前commitIndex。
一个简单的O（n）算法：
//更新commitIndex
res := 0
minBiggerMatchIndex := 99999999 //比commitIdx大的最小值
for i := 0; i < len(rf.matchIndex); i++ {
if rf.matchIndex[i] > rf.commitIndex {
res++
minBiggerMatchIndex = int(math.Min(float64(rf.matchIndex[i]), float64(minBiggerMatchIndex)))
}
}
//TODO 每次RPC只加1太慢了
if res > len(rf.peers)/2 {
rf.commitIndex = minBiggerMatchIndex
}
3.提交时，先对entries进行深拷贝，可以避免数据竞争。
entriesToApply := append([]Log{
}, rf.entries[(rf.lastApplied+1):(rf.commitIndex+1)]...)
测试时间
最后贴个lab2c测试时间：
Test (2C): basic persistence ...
... Passed -- 3.9 3 76 21621 6
Test (2C): more persistence ...
... Passed -- 17.2 5 928 218116 16
Test (2C): partitioned leader and one follower crash, leader restarts ...
... Passed -- 2.1 3 40 11352 4
Test (2C): Figure 8 ...
... Passed -- 41.9 5 1369 312992 59
Test (2C): unreliable agreement ...
... Passed -- 3.1 5 332 131912 246
Test (2C): Figure 8 (unreliable) ...
... Passed -- 38.0 5 11171 21985710 193
Test (2C): churn ...
... Passed -- 16.3 5 1596 1588205 667
Test (2C): unreliable churn ...
... Passed -- 16.3 5 1800 1136899 419
PASS
ok 6.5840/raft 139.113s