6.824 MapReduce lab总结

先总结一下架构：
首先是worker向master申请任务，master分配任务Task给worker，并且开启一个 go 协程对Task的状态进行监控，当时间超过10s则由master来将原来的Task重新放进maptasks(一个存放Task的chan)，这里master不会理会worker是crash了，还是某些原因导致运行速度很慢。当worke完成任务后则告诉master自己完成了任务，并且由master来更改相应的数据结构来表示该任务完成。

worker函数其实就是一个无限循环来取向master申请任务并做任务，因为worker需要在完成任务后继续申请任务并做任务。

所以Task结构需要维护一个Status，来表示worker该做map任务还是reduce任务，又或者是此时已经没有未分配 的任务，但是已分配的任务在其他worker还没有完成，此时worker向master申请任务时则需要分配一个Status为waiting的任务，worker收到之后就sleep一段时间，然后继续循环申请任务。

type Task struct {
	Phase int
	Status TaskStatus
	MapT MapTask
	ReduceT ReduceTask
}
type MapTask struct {
	// BaseTask
	 FileName string // 读取原始文件时需要的
	 TaskID int // 这个id在输出文件时需要用到
	 NReduces int // 这个是为了在输出文件时将 ihash(key) % NReduces时会使用到
	 // Status TaskStatus // 状态信息， worker在for循环中通过状态信息来得知自己要做什么任务
}
type ReduceTask struct {
	// BaseTask
	TaskID int // 只需要TaskID而不需要filename， 原因是因为我们输出时会按约定好的格式来输出文件
	NMaps int // mr-X-TaskID， 我们需要读取的文件格式，其中 0<= X < NMaps
	// 这么处理就不用去存中间文件的名字，因为每一个ReduceTask都会至多NMaps个文件，要维护一个[]string，写起代码挺繁琐的
	// Status TaskStatus // 状态信息.
}

MapTask需要维护一个filename，因为该filename是一开始输入的文件，我们不知道这些文件的名字，所以给每一个MapTask分配一个filename。
但是在ReduceTask的时候就不需要在维护文件名了，因为我们已经约定好了文件名为 mr-map任务ID-ihash后的reduceID

因此我们的reduceID只需要知道有几个map任务(nMaps),则worker在做reduce任务的时候只需要读取 mr - [0, nMaps) - ReduceID 共nMaps个文件则可以

监控是否超时的工作应该由master来做，一开始我让worker来做这个任务，最后运行测试时的打印语句表明根本没有在进行监控。换句话说，如果考虑在不同的机器运行worker，当其中的worker机器因为断电等原因崩溃时，你开的监控线程也没有了，所以监控应该让master来做

在生成任务，报告成功，报告失败等地方添加一个打印语句能让你在后续运行测试的时候能知道工作的流程，知道哪些worker被测试crash了，知道哪些任务成功退出

更好的数据结构能让代码变得更整洁，一开始我还想着把map输出的中间文件名回传，但就像我上面说的，其实没有这个必要的

坑： 在rpc的时候不要重复使用一个变量，每次调用时都重新定义一个变量。不然会出现你意想不到的值

怎么表示任务完成：我的做法是维护了一个 map[int]bool， 来表示是否完成，一开始我只想用 num == nMaps or nReduces的时候来表示该换成下一个阶段，但是后面考虑到如果一个任务超时但是没有崩溃，只是完成时间晚了一点，那么这个超时完成任务的worker也会报告成功，但是此时这个任务由于超时已经被分配给另一个worker，也就是说最后会一个任务被两个worker报告成功，会导致num被加了两次，所以这里单纯的用num来表示就有点不合理了。

我没有处理的情况： 可能会有新旧worker完成任务后导致旧文件被新文件覆盖的情况，也许可以 rename的时候再去rpc来查一下该任务是否完成，如果已经完成，则不rename，而是把该临时文件删除。

一定要记得加锁