endlessroad1991

@yzongyue 啊哈，你是对的。

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

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

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

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

以后说不定就是 ip+域名访问全面白名单化。白名单之内通过 mitm 保证内容可被分析，白名单之外直接掐断

早年从 windows 笔记本切换到 macbook air 的感觉：

cpu 不用太强，但硬盘一定要是 ssd 或 mac 用的那种 flash。

或多或少会有执行 Javascript 的能力。。

手抖

现在的搜索引擎爬虫或多或少会有 javasceipt 的能力，尤其是对排名较高的站点

@Troevil 你这么一说才发现。。 666

@Livid