本文共 1211 字，大约阅读时间需要 4 分钟。

MapReduce任务在运行时通过.so文件加载，这些文件由Go插件包中的文件加载。这些文件的名称通常以.so结尾。需要注意，如果在mr/目录中进行更改，可能需要重新构建相关的MapReduce插件，例如使用以下命令：

go build -buildmode=plugin ../mrapps/wc.go

在多个机器上运行时，所有的worker需要共享同一个文件系统。这意味着如果需要高效的文件访问，可能需要使用一个全局文件系统，如GFS。

为了使中间文件的管理更为简单，可以将文件名命名为mr-X-Y的格式，其中X表示Map任务的编号，Y表示Reduce任务的编号。

在Map任务中，需要一个方法来将中间的键值对存储到文件中，以便Reduce任务能够正确读取。一个常用的方法是使用Go的encoding/json包来将键值对写入JSON文件。例如：

err := json.Unmarshal([]byte(input), &kv)if err != nil {    // 处理错误}

在Map任务中，可以使用ihash(key)函数来确定哪个Reduce任务处理特定的键。ihash函数可以在worker.go中找到。

对于文件的读写和排序，可以参考mrsequential.go中的代码，学习如何高效地读取Map输入文件、排序中间键值对以及写入Reduce输出文件。

由于MapReduce的master作为一个RPC服务器，需要处理并发请求。在处理RPC请求时，必须正确地加锁共享数据，以避免竞态条件。

为了测试并发问题，可以使用Go的race检测工具：

go build -racego run -race

在test-mr.sh脚本中，可以看到如何在测试中启用race检测工具。

在实际应用中，需要确保Reduce任务能够等待直到所有Map任务都完成。可以通过在worker中定期询问master的工作状态，并使用time.Sleep()来等待任务。或者，在master中使用循环等待，直到获得足够的心跳信息判断worker是否崩溃。

由于master无法可靠地区分worker是否崩溃、卡住或过慢，建议在master中等待一定的时间（例如10秒）后，假设worker已经崩溃，并重新分配任务给其他worker。

为了测试崩溃恢复，可以使用mrapps/crash.go插件，它在Map和Reduce任务中随机退出。这样可以验证MapReduce系统在worker崩溃时的恢复机制。

为了确保在worker崩溃时不出现半写的文件，可以使用ioutil.TempFile创建临时文件，并在写入完成后通过os.Rename进行原子性重命名。这样可以避免数据不一致的问题。

在mr-tmp目录中运行test-mr.sh脚本时，所有中间和输出文件都会存储在该目录下。如果出现问题，可以在该目录中查找相关文件进行调试。

转载地址：http://xtqv.baihongyu.com/