我也终于刷完 MIT 6.824 2020 了

记得当年 2 还是 3 有个 unrealible figure 8 一直不能 100%过，调试的气死后来就弃了

唉，我连 lab1 都没有动力刷下去（话说这个好像不让放 github 上

@ysn2233 我是隔几天刷一下，不然太打击信心了

@arjen 再来刷下吧。。。我看到 github 上有不少人都放了，估计 MIT 的学生也不需要看我这种答案

@arjen 过 deadline 放 github 应该问题不大吧

666

同在写 6824 qaq 还没写完

之前只刷完了 lab1，2，lz 觉得 lab3，4 相比 lab2 分量怎样？

@PythonYXY 最复杂的是 lab2，lab34 相对简单些，lab3 需要给 raft 加快照，好多 lab2 的 bug 会冒出来，我觉得至少做完 lab3 才算完整吧

课程的论文都看完了？

@hallDrawnel 只写了 lab，所以只看了 raft

回复题主，帮你抓了个 bug 。

https://github.com/yzongyue/6.824-golabs-2020/blob/yzy/src/raft/raft_vote.go#L125 这里在 rf.changeRole()之前，应该确保 rf.role == Follower && rf.voteFor == -1 。

否则，该节点在 rf.changeRole()之前可能已经 approve 了其他节点在当前 term 的 vote request （并修改了 rf.voteFor ），然后在这里 rf.changeRole()的时候又投票给自己（ rf.voteFor = rf.me ）。这样该节点就会投出两个不同的票，从而可能造成当前 term 有两个不同节点成为 leader 的情况。

详细例子：假设 3 个节点 A，B，C 。
1. A 成为 candidate， 发送 vote request 给 B 。
2. B 收到 A 的 vote request 时仍然是 follower，因此批准 vote request 。
3. A 收到 B 的 approval，认为自己成为 leader 。
4. B 成为 candidate，并收到 C 的 approval，认为自己成为 leader 。

这里有一个问题是，为什么 2 之后，4 仍然可能发生？在 B 批准 A 的 vote request 时，B 重置了自己的 electionTimer： https://github.com/yzongyue/6.824-golabs-2020/blob/yzy/src/raft/raft_vote.go#L67 。所以 B 不应该再触发将自己变为 candidate 的逻辑 https://github.com/yzongyue/6.824-golabs-2020/blob/yzy/src/raft/raft.go#L415

我的理解是，2 和 4 之中，事实上先发生的是 4 （ B 触发自己变为 candidate 的逻辑 https://github.com/yzongyue/6.824-golabs-2020/blob/yzy/src/raft/raft.go#L415 ）。但很不幸，在调用 rf.startElection()时，go runtime scheduler 将本 goroutine 暂停，而切换到执行 2 的 goroutine （处理 A 的 vote request ）！如果把 rf.startElection() inline，就不会出现这个 bug 。这也能解释为什么这个 bug 很难复现：这依赖于 go runtime scheduler 对这些 concurrent events 的执行时机。

"如果把 rf.startElection() inline，就不会出现这个 bug 。“

请忽略这句话。。就算把 rf.startElection() inline，在那个 function 里面，仍然还有别的 function call 。所以仍然可能被 go runtime scheduler 切换出去。所以 bug 仍然可能存在

@endlessroad1991 多谢大神，确实需要先判断下，有时间我改改

@endlessroad1991 ps：大神们这么努力的嘛，6 小时前是凌晨三点？

lz 好，raft 里面 vote 部分，https://github.com/yzongyue/6.824-golabs-2020/blob/yzy/src/raft/raft_vote.go#L58 这里判断否 up-to-date，为何放在更改了自身 role （ https://github.com/yzongyue/6.824-golabs-2020/blob/yzy/src/raft/raft_vote.go#L55 ）的后面判断呢？我的理解是当网络 split，小部分独立节点一直 vote 会把 term 拉高，网络恢复时大部分节点虽然 term 比较低，但是 log 更新，所以不受影响，此时不应该把自己变成 follower ？

@yzs981130 啊我理解错了不好意思 在助教的 guide 里面有说 您是对的

@endlessroad1991 啊，，，不对，我发现之前的代码没问题，因为每次 change role 为 candidate 时，term += 1，
所以你给的情景不会出现同一 term 投出两票的情况

@yzongyue 啊哈，你是对的。

你当时 fail 的哪个 test ？是正确性问题（两个 server 同样 index，apply 了不同的 log ）还是某个 test 没能在规定时间内完成选主？

@endlessroad1991 忘了。。。当时没开 log 不确定到底是什么问题，能确定的是代码还有 bug