yzongyue / 6.824-golabs-2020 Goto Github PK

大佬，lab2D是没有test吗？然后我并没有看到代码里面有主动调用sendInstallSnapshot以及生成snapshot的情况，唯一一处是在startApplyLogs中，但是由于判断条件不会满足，所以不会去执行。
是2020版本要求就是这样，还是啥？

In src/shardmaster/server.go line 140

for i, val := range config.Shards {
	if count == avg {
		break
	}
	if val == 0 && count < avg {
		config.Shards[i] = gid
                // count++
	}
}

should increase count after assign gid

请问大佬，有没有遇到过调用如AppendEntries()这类RPC的时候返回false的情况呢？如果有的话，造成的原因是什么呢？
我看到您的代码中有对这个问题进行处理：

go func(args *AppendEntriesArgs, reply *AppendEntriesReply) {
    ok := rf.peers[peerIdx].Call("Raft.AppendEntries", args, reply)
    if !ok {
      time.Sleep(time.Millisecond * 10)
    }
    resCh <- ok
}(&args, &reply)

大致看了下源代码，感觉可能有以下问题:
当follower 1的election timer超时调用startElection()后，如果是rpc的RequestVote/AppendEntries先拿到锁并且发现有更大的term x, 那么follower 1会依然成为candidate并且term会是x + 1。那么一个刚当上leader的节点可能会被由follower转candidate的1替代掉，test的one()会失败。

如果理解错了，望谅解(我自己的lab 2当时卡在这里了)。

`func (m *Master) ReportTask(args *ReportTaskArgs, reply *ReportTaskReply) error {
m.mu.Lock()
defer m.mu.Unlock()

DPrintf("get report task: %+v, taskPhase: %+v", args, m.taskPhase)

if m.taskPhase != args.Phase || args.WorkerId != m.taskStats[args.Seq].WorkerId {
	return nil
}

if args.Done {
	m.taskStats[args.Seq].Status = TaskStatusFinish
} else {
	m.taskStats[args.Seq].Status = TaskStatusErr
}

go m.schedule()
return nil

}`

请问其中go m.schedule()的作用是什么？
为什么ReportTask后，tickSchedule就会不继续tick了呢？

貌似applier是有限制的，leader不能提交之前任期的日志
https://zhuanlan.zhihu.com/p/369989974

按照课程网页上的instruction运行了test，最后wc, indexer和crash三个测试都会失败

请问，为什么您的代码中持久化了这两个变量呢？

func (rf *Raft) getPersistData() []byte {
	w := new(bytes.Buffer)
	e := labgob.NewEncoder(w)
	e.Encode(rf.term)
	e.Encode(rf.voteFor)
	e.Encode(rf.commitIndex)
	e.Encode(rf.lastSnapshotIndex)
	e.Encode(rf.lastSnapshotTerm)
	e.Encode(rf.logEntries)
	data := w.Bytes()
	return data
}

其实我赞成您的这个做法，但在论文中并没有提到需要持久化这两个变量，尤其是lastApplied。
如果没有持久化lastApplied，节点在reboot之后，应该会根据commitIndex更新lastApplied，这样便会重复apply在reboot之前的entry。
难道是因为apply的状态本来就是不稳定的？也就是数据都是在内存中？🤣而不是apply到磁盘里边？

lab3b里正常的snapshot到这里就不行了，连续出现 wrong group，没法向前推进，不知到你有没有出现类似问题