MIT 6.824 Raft实现中Goroutine调度异常致心跳超时问题排查

环境与背景 #

• 正在完成MIT 6.824 Lab2的基础Raft共识算法实现
• 实验环境：Windows WSL2 + Ubuntu22.04.2 LTS，Go版本go1.20.1 linux/amd64，CPU为Intel i7-12650h
• Leader当选后，为每个集群成员启动logSyncer Goroutine，定期检查日志复制需求或发送心跳，核心代码如下：

func (rf *Raft) logSyncer(server int, expectTerm int) {
    noOpsCnt := -1
    for {
       if rf.killed() {
           return
       }
       rf.mu.Lock()

       if rf.currentTerm != expectTerm {
           rf.mu.Unlock()
           return
       }
        
       curLastLogIndex := rf.getGlobalIndex(len(rf.log) - 1)

       if curLastLogIndex >= rf.nextIdx[server] || (noOpsCnt+1)%5 == 0 {
           // 触发条件：
           // 1. 已过一个心跳周期（5*20ms ~ 5*30ms）
           // 2. 有新日志需要复制给Follower
           rf.syncEntriesToFollower(server, expectTerm)
           noOpsCnt = 0
       } else {
           // 无操作，仅递增计数器
           noOpsCnt++
       }
       rf.mu.Unlock()
       
       // 循环前休眠20~30ms
       randSleepTime := GetRandom(20, 30)
       time.Sleep(time.Duration(randSleepTime))
    }
} 

问题现象 #

启动40个子进程多次执行日志复制测试时，每2500次会出现一次异常：Leader在500ms~1s内未发送心跳，导致Follower触发新一轮选举，测试失败。

排查过程 #

1. 怀疑互斥锁rf.mu阻塞，添加超时200ms的check() Goroutine打印所有Goroutine栈，未触发
2. 添加时间打点后发现，前一次循环结束到下一次循环开始的间隔长达1s，而sleep仅耗时26ms，相关日志：

017048 TEST Server 0 Leader Term 1, logSyncer-> Server 2, noOpsCnt 3,
 (tBeginLoop - tPrevEndLoop) takes 1038 ms, (tKill- tBeginLoop) takes 0 ms, (tLock- tKill) takes 0 ms, (tAfterSleep - tBeforeSleep) takes 26ms

可能的原因分析 #

• WSL2虚拟化调度延迟：WSL2运行在Hyper-V虚拟机上，Windows主机的CPU调度可能给虚拟机分配不连续的时间片，尤其当主机CPU负载高或使用大小核架构（i7-12650h是大小核）时，WSL2进程可能被长时间挂起，导致Goroutine调度延迟。
• Go Goroutine抢占不及时：Go 1.20默认启用异步抢占，但如果rf.syncEntriesToFollower函数在持有锁时执行了长时间CPU密集型操作（比如大量日志遍历、无阻塞循环），可能导致logSyncer Goroutine被延迟调度。
• GetRandom函数实现错误：虽然日志显示sleep耗时正常，但需确认该函数是否真的返回20-30之间的整数，是否存在极端情况返回超大值（比如函数逻辑错误返回2000-3000）。
• 多进程资源竞争：40个子进程同时运行可能耗尽WSL2的CPU、内存资源，系统进入高负载状态，进程被调度器延迟唤醒。
• rf.killed()实现问题：如果rf.killed()内部涉及锁或非原子操作，极端情况下可能出现延迟，建议改用atomic.Bool实现无锁检查。

验证建议 #

1. 替换GetRandom为Go标准库实现：rand.Intn(11) + 20，排除随机数生成错误
2. 关闭WSL2中无关进程，降低系统负载，观察是否仍出现异常
3. 检查rf.syncEntriesToFollower函数，尽量减少锁持有时间，避免在锁内执行CPU密集型操作
4. 尝试在原生Linux环境运行测试，确认是否是WSL2的虚拟化调度问题

内容的提问来源于stack exchange，提问作者wsxzei