MIT 6.5840 Lab1要求用Go实现分布式MapReduce框架，核心是修改mr/coordinator.go、mr/worker.go和mr/rpc.go三个文件，构建Coordinator（任务调度与状态管理）和Worker（执行Map/Reduce任务）角色，通过RPC通信协调多进程协作，并支持超时重发、阶段切换与容错。
Go 本身不提供开箱即用的分布式 MapReduce 运行时，但你可以用标准库 + 明确的进程边界 + RPC/GRPC 实现它。关键不是“有没有”，而是“怎么划清 Coordinator、Worker、数据流、失败恢复这四层责任”。
Coordinator 怎么调度任务又不阻塞
Coordinator 的核心是状态机 + 非阻塞通信。不能用全局锁保护所有任务状态，否则并发 Worker 一多就卡死。
- 用
sync.Map存储每个Task的State（Working/Done/Waiting），避免读写锁争用 - 为每个 Worker 分配独立的
chan *Task（比如TaskChannelMap和TaskChannelReduce），而不是让所有 Worker 从同一个 channel 拿任务——否则会抢到重复任务 - 超时必须主动检测：
time.AfterFunc(FixedTimeOut * time.Second, func(){...})启动后，Worker 完成时要显式调用 cancel；否则超时后 Coordinator 会重发，造成重复计算 - 不要在
Coordinator.Example这类 RPC 方法里做耗时操作（如磁盘 I/O 或 sleep），否则整个 RPC server 线程会被拖住
Worker 怎么安全地执行 Map/Reduce 又不崩溃主进程
Worker 是无状态的短生命周期进程，它的错误不能让 Coordinator 挂掉，也不能让其他 Worker 受影响。
- 每个
MapTask或ReduceTask必须在独立 goroutine 中执行，并用recover()捕获 panic —— 否则一个任务 panic 会导致整个 Worker 进程退出 - 文件读写必须带完整路径和错误检查：
os.Open(task.FileName)失败时，不能静默跳过，而要通过 RPC 回传error给 Coordinator 标记该任务失败 - Reduce 阶段依赖 Map 输出文件（如
mr-out-0-0），必须先os.Stat确认文件存在且非空，再读取；否则io.EOF或unexpected EOF会直接 crash - RPC 调用要用带上下文的版本：
callWithContext(ctx, "Coordinator.TaskDone", &args, &reply)，避免 Worker 卡死时 Coordinator 无限等待
MapReduce 的 shuffle 阶段怎么在 Go 里落地
Shuffle 不是魔法，就是把 Map 输出按 key 散列到不同 Reduce 文件里。Go 里没有现成的 partition(key, nReduce)，得自己写。
- Map 阶段输出不能直接写成单个大文件，必须拆成
nReduce个临时文件（如mr-tmp-m-0-0,mr-tmp-m-0-1…），每个对应一个 Reduce ID - key 的散列函数别用
hash/fnv这种非确定性哈希（不同 Go 版本行为可能变），推荐用fmt.Sprintf("%d", hash)%nReduce或int64(hash.Sum32()) % int64(nReduce) - Reduce 阶段读取时，要聚合所有
mr-tmp-m-*-R文件（R是当前 ReduceID），不能只读一个 —— 这是 MIT 6.824 Lab1 测试里最常 fail 的点 - 中间文件名必须严格一致：Coordinator 生成的
MapTask.FileName、Worker 写的mr-tmp-m-0-R、Reduce 读的mr-tmp-m-*-R，三者命名规则错一个，shuffle 就断链
用 go-zero/mr 包做本地并行加速要注意什么
go-zero/mr 是单机并行框架，不是分布式系统。它能帮你省掉 goroutine 管理，但不能替代 Coordinator/Worker 架构。
- 它的
MapReduce函数只适合 CPU-bound、无状态、输入可切分的任务（如批量 JSON 解析、图像缩放）；不适合需要跨节点 shuffle 的词频统计 -
WithWorkers(n)设置的是 goroutine 数量，不是机器数 —— 在 1 台机器上设 100 个 worker，不如设 8 个（匹配 CPU 核数），多了反而因调度开销降低吞吐 - 它的
Reducer是串行聚合的，传入的[]int是所有 Map 结果的全量切片；如果 Map 输出 1GB 数据，Reducer 就得在内存里 hold 1GB，容易 OOM - 不要试图用
go-zero/mr替代 RPC 通信逻辑 —— 它没有网络层、没有故障转移、没有任务持久化，Coordinator 进程一挂，所有进度全丢
真正难的从来不是写 Mapper 和 Reducer 函数，而是让 Coordinator 知道哪个 Worker 活着、哪个任务卡住了、哪个中间文件写了一半就崩了、以及重启后怎么续跑。这些逻辑没覆盖全，分布式 MapReduce 就只是个能跑通 demo 的玩具。
