1. 从零开始：理解MapReduce与MIT 6.5840 Lab1
如果你对分布式计算感兴趣，或者正在学习MIT 6.5840（也就是大家更熟悉的6.824）这门神课，那么Lab1绝对是你绕不开的起点。这个实验的目标非常明确：用Go语言，从零开始实现一个分布式MapReduce框架。别被“分布式”和“框架”这些词吓到，说白了，就是让你亲手搭建一个系统，能把一个大任务（比如统计一堆文档的词频）拆成很多小份，分给多台机器（或者多个进程）同时算，最后再把结果汇总起来。这和我们生活中分工合作完成一个大项目，原理上是一模一样的。
我当年第一次做这个实验时，感觉既兴奋又头大。兴奋是因为终于要动手实现教科书里的经典模型了，头大是因为官方给的提示（Hints）虽然全，但就像一张藏宝图，你得自己摸索着把碎片拼起来。网上很多分享直接给最终代码，但我觉得那样学不到精髓。这篇文章，我会结合我自己的实战经验，带你一步步拆解Lab1，不仅告诉你怎么做，更分享我踩过的坑和当时的思考过程。我们的目标不是仅仅通过测试，而是真正理解一个分布式计算核心是如何被构建起来的。
实验提供了基础代码骨架，包括一个顺序执行的MapReduce版本（mrsequential.go）和词频统计的例子（wc.go）。你的工作就是以此为蓝本，将其改造成一个分布式的系统。这个系统由两部分组成：一个协调者（Coordinator）和多个工作者（Worker）。协调者负责管理所有任务的状态和分发，工作者则主动向协调者请求任务，执行具体的Map或Reduce计算。整个通信过程通过RPC（远程过程调用）完成。听起来是不是有点像项目经理和程序员的关系？项目经理（Coordinator）手里有需求清单（任务列表），程序员（Worker）们主动来领任务，做完后再汇报。
2. 实验环境与前期准备：磨刀不误砍柴工
在撸起袖子写代码之前，花点时间把环境搭好、把规则吃透，能让你后续的开发顺畅很多。我当初就是太心急，直接开干，结果在环境问题上卡了半天。
2.1 基础环境搭建
首先，确保你对Go语言有基本的了解。不需要多深入，但变量、函数、结构体、goroutine和channel这些概念得清楚。如果感觉生疏，快速过一遍Go的官方教程或者一篇速成指南就够了，我当初就是花了两天时间速通的。
其次，配置好Go开发环境。我强烈推荐使用VSCode，配合Go插件，代码提示和跳转会非常方便。实验代码需要在特定的目录结构下运行，一个常见的“坑”是：同一个文件目录下不能有多个package main。如果你遇到了相关报错，很可能是因为文件组织不对。我的解决办法是严格按照实验提供的main/和mr/目录结构来放置代码，不要随意移动文件。
最后，也是最重要的，认真阅读MapReduce的原始论文。不用逐字逐句深究所有细节，但你必须理解其核心思想：Map阶段将输入数据转换成键值对，Shuffle阶段根据键进行分组和排序，Reduce阶段对每组数据进行聚合。脑子里有了这个清晰的三阶段流水线，后面的设计才有依据。
2.2 理解你的任务与游戏规则
实验的mrsequential.go已经展示了一个完整的、但非分布式的MapReduce流程。你的工作就是让它“分布式”起来。具体来说，你需要修改和实现三个核心文件：
mr/coordinator.go: 协调者逻辑，任务的大脑。mr/worker.go: 工作者逻辑，任务的双手。mr/rpc.go: 协调者与工作者之间的通信协议定义。
而main/mrcoordinator.go和main/mrworker.go是程序的入口，一般不需要改动。
实验通过一个名为test-mr.sh的脚本进行测试。当你的实现完全正确时，会看到一连串的PASS，最终输出*** PASSED ALL TESTS，那一刻的成就感是无与伦比的。为了达到这个目标，你必须遵守一些硬性规则：
- 中间文件命名：Map任务生成的中间文件必须命名为
mr-X-Y，其中X是Map任务编号，Y是Reduce任务编号。这是后续Reduce任务能够正确找到对应输入数据的约定。 - 输出文件格式：Reduce任务的最终输出文件为
mr-out-X，每一行必须是"%v %v"的格式，即“键 值”。mrsequential.go里的写法就是标准答案。 - 容错与超时：工作者可能会崩溃或执行缓慢。协调者必须能检测到超时的任务（比如10秒未完成），并将其重新分配给其他空闲的工作者。这是分布式系统可靠性的关键。
- 优雅退出：当所有任务完成后，协调者和工作者都应该能正常退出。一个简单的实现是：工作者如果发现无法连接到协调者（调用RPC失败），可以认为作业已完成，自己退出。
官方提供的Hints非常宝贵，几乎指出了实现路径上的每一个关键路标。我的建议是，先通读一遍所有Hints，在脑子里形成一个模糊的框架，然后开始动手。每实现一个部分，再回头看看对应的Hint，常有“原来如此”的顿悟感。
3. 核心架构设计：定义你的数据结构
这是整个实验最核心，也最让人纠结的一步。数据结构定义得好，后面的逻辑就清晰流畅；定义得不好，就会陷入不停打补丁、代码越来越乱的境地。我最初的版本就反复重构了好几次。
3.1 任务（Task）是什么？
首先，我们需要抽象出“任务”这个概念。一个任务需要包含哪些信息？
type Task struct { Type TaskType // 任务类型：Map、Reduce、等待、退出 Id int // 任务唯一ID FileName string // 对于Map任务，这是输入文件；对于Reduce，可能是文件列表 NReduce int // Reduce任务的总数，用于Map阶段的分桶 // 注意：Reduce任务可能需要一个文件名列表，这里简化用FileName，实际可扩展 }这里我定义了一个TaskType枚举，用来区分任务状态。除了Map和Reduce，我还增加了WaitingTask（表示所有任务都在进行中，请等待）和ExitTask（表示所有作业已完成，工作者可以退出）。这能让工作者的逻辑更清晰。
3.2 协调者（Coordinator）如何管理全局？
协调者是中枢，它需要掌握所有任务的信息、状态，并负责任务队列的管理。
type Coordinator struct { mu sync.Mutex // 并发安全必备 state int // 整个作业的阶段：Map阶段、Reduce阶段、全部完成 mapTasks chan *Task // 存放待分配的Map任务队列 reduceTasks chan *Task // 存放待分配的Reduce任务队列 taskMeta map[int]*TaskMetaInfo // 记录所有任务的元数据 nReduce int files []string // 输入文件列表 }我使用了两个Channel（mapTasks和reduceTasks）作为任务队列。Channel天然是并发安全的，非常适合这种生产者-消费者模型。协调者生产任务放入Channel，工作者消费（请求）任务。
关键点在于taskMeta。它记录了每个任务的详细信息，而不仅仅是任务本身。为什么需要这个？因为我们要实现容错！
type TaskMetaInfo struct { taskPtr *Task state TaskState // 任务状态：等待中、执行中、已完成 startTime time.Time // 任务开始执行的时间，用于判断超时 }TaskState可以是Idle（等待分配）、InProgress（正在执行）、Completed（已完成）。当工作者领取一个任务时，协调者需要将对应任务的状态从Idle改为InProgress，并记录开始时间。这样，另一个后台的goroutine就可以定期扫描taskMeta，找出那些状态是InProgress且已超时（例如超过10秒）的任务，将它们的状态重置为Idle，并重新放回任务队列。这就是容错机制的核心。
3.3 工作者（Worker）的生命周期
工作者的逻辑是一个大循环：
- 通过RPC向协调者请求一个任务。
- 根据收到的任务类型（
Task.Type）执行不同的操作。 - 执行完毕后，通知协调者该任务已完成。
- 如果收到
ExitTask，则退出循环。
这个循环非常简单，复杂的工作都封装在doMapTask和doReduceTask函数里，以及协调者的状态管理里。
4. 分步实现：从Map到Reduce的完整流程
有了清晰的数据结构，我们就可以像搭积木一样实现各个模块了。让我们按照任务执行的顺序来走一遍。
4.1 阶段一：Map任务的分配与执行
协调者初始化：在MakeCoordinator函数中，我们根据传入的文件列表files和Reduce数量nReduce，创建所有的Map任务，并将它们放入mapTasks这个Channel中。同时，在taskMeta中为每个任务创建TaskMetaInfo，初始状态为Idle。
工作者请求任务：工作者调用Coordinator.PullTaskRPC方法。协调者从这个RPC方法中需要做几件事：
- 加锁（保证并发安全）。
- 根据当前
state决定从哪个Channel取任务（Map阶段就从mapTasks取）。 - 从Channel中取出一个任务，检查其在
taskMeta中的状态是否为Idle（防止重复分配已在进行中的任务）。 - 将其状态更新为
InProgress，记录startTime。 - 将任务对象返回给工作者。
- 解锁。
工作者执行Map：工作者拿到任务后，调用doMapTask函数。这个过程和mrsequential.go里的Map部分很像，但有一个至关重要的区别：
- 读取
Task.FileName指定的文件内容。 - 调用用户提供的
mapF函数，生成键值对列表（intermediate）。 - 关键步骤：分桶（Partitioning）。不能像顺序版本那样把所有键值对都混在一起。我们需要根据键的哈希值，将
intermediate中的每个键值对分配到nReduce个桶中的一个。这是为了确保同一个键最终会被送到同一个Reduce任务去处理。代码大致如下：partitions := make([][]KeyValue, nReduce) for _, kv := range intermediate { bucketIndex := ihash(kv.Key) % nReduce partitions[bucketIndex] = append(partitions[bucketIndex], kv) } - 将每个桶（即一个
[]KeyValue切片）写入到对应的中间文件，文件名格式为mr-<MapTaskId>-<ReduceBucketIndex>。这里通常使用JSON编码写入，方便Reduce阶段读取。
工作者上报完成：Map任务执行完后，工作者调用Coordinator.MarkDoneRPC，传入任务ID。协调者收到后，将对应任务在taskMeta中的状态标记为Completed。
4.2 阶段转换：协调者如何知道该进入Reduce阶段了？
这是状态管理的核心。协调者需要在一个地方判断“所有Map任务是否都完成了”。我选择在PullTaskRPC方法中加入这个判断逻辑。
当协调者处于Map阶段，且mapTasks这个Channel为空时，并不意味着所有Map都完成了，因为可能有任务还在执行中（状态为InProgress），或者失败了要重试（状态会变回Idle）。
因此，正确的判断逻辑是：遍历taskMeta中所有Map任务，如果没有任何一个任务的状态是Idle或InProgress，即所有任务都是Completed，那么Map阶段就结束了。
一旦检测到Map阶段结束，协调者需要做几件事：
- 将
state从MapPhase改为ReducePhase。 - 创建所有的Reduce任务。这里的关键是，每个Reduce任务需要知道它应该处理哪些中间文件。根据命名规则
mr-X-Y，第Y个Reduce任务需要收集所有mr-*-Y的文件。我们可以通过扫描当前工作目录来构建这个文件列表。 - 将这些Reduce任务放入
reduceTasksChannel，并初始化它们在taskMeta中的元数据。
4.3 阶段二：Reduce任务的分配与执行
Reduce任务的分配逻辑和Map任务完全一样。工作者请求任务，协调者从reduceTasksChannel中分配，并更新状态。
工作者执行Reduce：这是doReduceTask函数的工作。
- 根据任务ID（即Reduce编号），读取所有对应的中间文件（例如所有
mr-*-2的文件）。 - 将所有这些文件中的键值对解码并加载到一个大数组中。
- 对这个数组按键进行排序。这一步非常重要，它使得相同键的键值对排列在一起，是高效执行Reduce的前提。我们可以直接复用
mrsequential.go中的sort.Sort(ByKey(...))逻辑。 - 遍历排序后的数组，将相同键的值聚合到一个列表里，然后调用用户提供的
reduceF函数，得到最终结果。 - 将最终结果（键和聚合后的值）写入到输出文件
mr-out-<ReduceTaskId>中。
最终完成：当所有Reduce任务都标记为Completed后，协调者将state改为DonePhase。此后，当工作者再来请求任务时，协调者可以返回ExitTask。工作者收到后便退出循环，整个程序运行结束。
5. 攻克难点：容错、并发与测试
实现基本流程后，你的代码可能能通过一部分测试，但要通过所有测试（尤其是最后的crash test），就必须完善容错和并发控制。
5.1 实现超时与重试机制
这是Lab1的精华所在。我们需要一个独立的goroutine，在协调者内部定期检查超时任务。
func (c *Coordinator) checkTimeoutRoutine() { for { time.Sleep(2 * time.Second) // 每2秒检查一次 c.mu.Lock() if c.state == DonePhase { c.mu.Unlock() return } now := time.Now() for _, meta := range c.taskMeta { if meta.state == InProgress && now.Sub(meta.startTime) > 10*time.Second { // 任务超时 meta.state = Idle // 重置状态 // 根据任务类型，重新放回对应的任务队列 if meta.taskPtr.Type == MapTask { c.mapTasks <- meta.taskPtr } else if meta.taskPtr.Type == ReduceTask { c.reduceTasks <- meta.taskPtr } } } c.mu.Unlock() } }在MakeCoordinator中启动这个goroutine。注意，操作taskMeta和任务队列时，必须加锁，因为PullTask、MarkDone和这个检查例程会并发访问这些共享数据。
5.2 处理“任务已完成”的重复通知
一个任务可能因为网络延迟等原因，工作者在超时后已经上报了完成，但协调者又把它重新分配了。当之前那个“慢吞吞”的完成通知终于到达时，协调者应该能正确处理——即忽略这个对已完成或已重新分配任务的完成通知。在MarkDoneRPC中，我们只更新状态为InProgress的任务。如果任务状态已经是Completed或Idle（意味着已被重新分配），则直接忽略。
5.3 通过竞争检测（Race Detector）
Go提供了一个强大的工具：go run -race。实验的测试脚本也提示你可以用它来检测数据竞争。我在第一次写完代码通过基础测试后，一开竞争检测，立刻报出好几个数据竞争（data race）。问题就出在，我虽然用了Channel，但taskMeta这个map的读写是在多个goroutine中进行的，光靠Channel保护不了它。必须用互斥锁（sync.Mutex）将访问taskMeta的代码块保护起来，包括PullTask、MarkDone和checkTimeoutRoutine。加上锁之后，竞争警告就消失了。
5.4 应对Crash Test
test-mr.sh最后的crash test会随机地、强制地杀死一些工作者进程，以此来测试你的框架的鲁棒性。如果你的超时重试机制和状态管理做得正确，那么即使工作者中途崩溃，协调者也会在超时后把任务重新派发给其他存活的工作者，作业最终依然能够完成。这个过程完全由你的协调者逻辑自动处理，是分布式系统“高可用”特性的直接体现。
6. 调试技巧与个人心得
做这个实验，调试是个技术活。你不能只靠打印日志，因为多个工作者和协调者同时在输出，信息会混在一起。
- 为日志加上前缀：在每个打印语句前加上
[Coordinator]或[Worker <ID>]这样的前缀，能极大提升日志的可读性。你甚至可以给每个工作者生成一个随机ID。 - 分阶段测试：不要想着一口气吃成胖子。先让单个Map任务跑通，然后测试多个Map任务并行，再测试Map到Reduce的转换，最后加上超时和容错。
test-mr.sh提供了很多独立的测试用例，你可以单独运行其中的某一个，例如go test -run TestBasic。 - 善用Hints：当你卡住时，再仔细读读Hints。我保证，答案几乎都在里面。比如，它提示你用JSON编码中间文件、用
ihash函数分桶、注意10秒后再调度备份任务等，这些都是精确的指引。 - 关于代码结构：我的经验是，不要一开始就追求一个“完美”的设计。可以像写草稿一样，先实现一个能跑通简单场景的版本。在实现过程中，你自然会发现问题（比如“我需要一个地方记录任务开始时间”），然后逐步将新的字段和逻辑加入你的结构体和函数。这种迭代式的开发方式，比前期过度设计更有效。
完成MIT 6.5840 Lab1，远不止是获得一个通过的测试结果。它是一次完整的、从理论到实践的分布式系统启蒙。你会对任务调度、状态同步、容错处理、并发控制这些概念有切肤之感的理解。这种自己亲手把一个个零件组装起来，最终看到一个分布式系统运转起来的体验，是只看论文和代码无法比拟的。它带给你的信心和兴趣，会支撑着你继续挑战后面更复杂的Lab，比如Raft和K/V服务。所以，动手去实现吧，遇到问题就回来看看这篇文章，或者去课程讨论区找找灵感。记住，每一个你踩过的坑，都是通往精通之路的坚实台阶。
