因为字节的镜像计划,所以开始学习这门课.lab1前前后后花8天时间
基本思路: 多个woker 请求任务master分配任务woker执行任务 回访ACKwoker再次请求任务master分配贴上我的结构属性,给大家参考.
type Task struct {
//task kind 1 表示map 2表示reduce 3表示暂停1s 4表示任务全部完成 暂停1s
Kind int
//Map fileName kind=1 filename是要解析的文章
//Reduce 完成任务时递交task 等待commit的文件名
FileName string
//taskId
Id int32
// Map任务生成的中间文件
// reduce任务要解析的文件名
InterfileList []string
// Map 划分成多少个中间文件
Nreduce int
}
type Coordinator struct {
// Your definitions here.
MapIndex int32
// 任务map 1表示没有开始 2表示在执行 3表示已经完成
TaskMap map[string]int
MapFlag bool
//记录所有的中间文件 1表示没有开始 2表示在执行 3表示已经完成
IntermediateFileIndex int32
Intermediatefile map[string]int
//生成多少个 中间文件
Nreduce int
//超时任务
MapOvetTimeMap map[int32]int32
ReduceOverTimeMap map[int32]int32
}
我遇到的坑点
分析测试方法
mrapps文件夹里面对应着每一个test,里面每一个文件都有一个Map和Reduce方法,测试是通过更换这两个方法来实现的.
如何解决并发冲突:1.master分配任务时大量使用锁
2.使用channel机制(因为我对go channerl不熟悉,所以没做)
crashTest一直通不过:这里我把测试的源码看了一遍,并且单独测试crashTest,发现有些时候reduce任务会重复执行,而且结果每一行的value数量都是一样的个数,都多几个.中间文件多几组.
后来多加了两个属性 MapOvetTimeMap ReduceOverTimeMap用于判断超时任务 通过
commit机制这个非常关键,比如当map任务开始时,我们会创建一个文件,但是这个文件不一定完整,所以我们可以在ACK的时候将这个文件正确命名,这个方法可以有效解决重复任务的问题.
最后go语言不太熟悉,不熟悉的语言用起来就会总是要去做一些类型转换.
黑匣子心理,遇到问题就宕机,浪费了许多时间.
有很多问题,我没有遇到或者没体现出来,一些方法可能解决不止一种情况.但是我都是盯着BUG一个一个的改,导致后面代码很乱,缝缝补补,面多了加水,水多了加面.
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)