我也终于刷完 MIT 6.824 2020 了

[yzongyue]

今年只是 lab1 改版，后面的实验和前面几年没有区别；目前的代码有个 test 偶现了一次 FAIL， 又跑了几百次没跑出来。。。 源码在 github

[ysn2233]

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

[arjen]

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

[yzongyue]

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

[yzongyue]

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

[Weny]

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

[aaahhh123]

666

[polebug]

同在写 6824 qaq 还没写完

[PythonYXY]

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

[yzongyue]

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

[hallDrawnel]

课程的论文都看完了？

[yzongyue]

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

[endlessroad1991]

回复题主，帮你抓了个 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 的执行时机。

[endlessroad1991]

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

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

[yzongyue]

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

[yzongyue]

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

[yzs981130]

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]

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

[yzongyue]

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

[endlessroad1991]

@yzongyue 啊哈，你是对的。

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

[yzongyue]

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