2020 6.824 的 Raft Lab 2B

前言

做2020的MIT6.824,完成了实验Raft Lab2B,通过了测试,对于之前一个实验请参考2020 6.824 的 Raft Lab 2A

这个实验坑明显比2A多,花了大概3周时间才全部pass,其中20%时间在理解,10%时间在coding,剩下70%时间在debug,于是顺便养成看log的习惯

Lab2B 部分我也是没有做优化的,也就是这个部分的优化实现,没有conflictIndex以及conflictTerm同样也是可以通过Lab2B的Test的

下面有这个链接对我的实验测试很有帮助,主要是为了多测测试,保证没有因为概率通过而miss掉的一些测试用例

  1. 并行运行测试的shellscript
##每20个test并行运行,运行100次2B的test
bash test_many.sh 100 20 2B

实验要求是不能参考别人的代码的,这个我没有完全准守,下面是我参考的链接。不过,使用别人的代码同时也给我挖了个坑,就是把别人的代码片段copy过来自己用,有时候一些边界条件特别容易忽略,所以其实看看别人的思路(框架),再结合自己的代码自己实现,可以少采坑,当然,最好是自己重头到尾撸一遍。好了,下面是我参考的实现

  1. 2017 版本的Raft
  2. 2020 版本的Raft
  3. C++ 版本的Raft

一、Raft2B

在整体框架上我还是沿用了我Raft 2A的设计,那么2B的实现主要完善了2A中的两个方法

  1. AppendEntries()
  2. SendHeartbeat()

同时,需要完成一些log同步相关的helper function


二、SendHeartbeat

2.1 框架

func (rf *Raft) SendHeartbeat() {
   
   for !rf.killed() {
   
   	...
   		for i := 0; i < len(rf.peers); i++ {
   
   			... 
   			args := AppendEntriesArgs{
   
   				...
   			}

   			go func(p int, args *AppendEntriesArgs) {
   
   				...
   				if reply.Success == true {
   
   					//成功处理
   					...
   				} else {
   
   					//失败处理
   					...
   				}
   			}(i, &args)
   		}
   	}()
   }
}

2.2、发送部分的AppendEntriesArgs

nextIndex := rf.nextIndex[i]
	entries := make([]LogEntry, 0)
	entries = append(entries, rf.log[nextIndex:]...)
	args := AppendEntriesArgs{
   
		Term:         rf.currentTerm,
		LeaderId:     rf.me,
		Entries:      entries,
		PrevLogIndex: rf.getPrevLogIndex(i),
		PrevLogTerm:  rf.getPrevLogTerm(i),
		LeaderCommit: rf.commitIndex,
}
  1. AppendEntriesArgs增加了Entries, PrevLogIndex, PrevLogTerm, LeaderCommit
    • PrevLogIndex是leader对每个peer记录nextIndex的前一个,也就是nextIndex-1
    • PrevLogTerm是PrevLogIndex对应的Term
    • Entrries 是针对peer而言的,是leader给peer发送的entries,至于发什么entries,取决于leader对peer记录的nextIndex之后的log,也就是append(entries, rf.log[nextIndex:]…)
  2. 前面提到的nextIndex是leader临时生成的,也就是在convertToLeader时候生成的
func (rf *Raft) convertToLeader() {
   
	...
	//每个节点下一次应该接收的日志的index(初始化为Leader节点最后一个日志的Index + 1)
	rf.nextIndex = make([]int, len(rf.peers))
	for i := 0; i < len(rf.peers); i++ {
   
		rf.nextIndex[i] = rf.getLastLogIndex() + 1
	}
	//每个节点已经复制的日志的最大的索引(初始化为0,之后递增)
	//init match index is [0 0 0]
	rf.matchIndex = make([]int, len(rf.peers))
}

2.3、接收部分的处理

2.3.1 成功处理

需要跟新nextIndex以及matchIndex, 注意nextIndex的值以及log的长度可能已经被别的线程修改了,所以对于matchIndex

rf.matchIndex[p] = args.PrevLogIndex + len(args.Entries)
rf.nextIndex[p] = rf.matchIndex[p] + 1

同时,需要查看commitIndex是否需要跟新,对应paper就是,其实就是找一个MatchIndex的中位数N,如果N更大则跟新当前MatchIndex

If there exists an N s

### 6.824 Raft 实验测试脚本下载与示例 针对6.824课程中的Raft实验,通常会使用Go语言编写测试脚本来验证实现的正确性和稳定性。这些测试脚本位于项目的`tests`目录下,并且可以通过执行特定命令来运行。 #### 获取项目源码及其测试套件 为了获得完整的测试环境,建议克隆官方GitHub仓库: ```bash git clone https://github.com/username/lab.git cd lab/src/raft ``` 这里假设`username`代表维护该实验室代码的具体账户名,在实际操作时应替换为正确的用户名或组织名称。 #### 运行基本测试案例 一旦获得了源码库,就可以利用内置工具来进行初步的功能性检测: ```bash go test -run 2A ``` 上述命令专门用于检验Leader Election部分是否正常工作[^3]。当所有指定条件满足后,终端将会显示出相应的成功消息以及耗时统计信息。 #### 调试复杂场景下的行为表现 对于更深入的问题排查或是性能瓶颈分析,则需依赖于定制化的shell辅助程序——例如提到过的`test-mr.sh`。此脚本负责在子目录`mr-tmp`内启动一系列流程;遇到异常状况时能够暂停后续动作以便审查中间产物[^1]。 此外,面对偶发性的故障现象(比如每几十次甚至上百次才重现一次的情况),应当考虑增强日志记录强度,即编辑配置文件`config.go`加入更多诊断语句帮助定位潜在缺陷所在位置[^2]。 #### 示例:调整Shell Script以适应不同需求 下面给出了一段经过简单改造后的`test-mr.sh`片段,旨在展示如何设置断点从而便于观察具体环节的状态变化: ```bash #!/bin/bash set -e # 遇到任何错误立即终止整个脚本执行 # 原始逻辑... ./your_test_program || exit $? # 如果测试失败则停止进一步的操作 echo "Test failed, inspecting intermediate files..." ls mr-p "Press enter to continue or Ctrl+C to abort..." # 提供人工干预机会 ``` 通过这种方式可以在每次出现问题之后手动决定下一步行动方向,而不会因为自动清理机制而导致有价值线索丢失。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值