Map/Reduce 工作机制分析 --- 错误处理机制

前言

　　对于Hadoop集群来说，节点损坏是非常常见的现象。

　　而Hadoop一个很大的特点就是某个节点的损坏，不会影响到整个分布式任务的运行。

　　下面就来分析Hadoop平台是如何做到的。

硬件故障

　　硬件故障可以分为两种 - JobTracker节点损坏和TaskTracker节点损坏。

　　1. JobTracker节点损坏

　　　　这是Hadoop集群中最为严重的错误。

　　　　出现了这种错误，那就只能重新选择JobTracker节点，而在选择期，所有的任务都必须停掉，而且当前已经完成了的任务也必须通通重来。

　　2. TaskTracker节点损坏

　　　　这是Hadoop集群中最常见的错误。对于这类错误，Hadoop有完好的错误处理机制。

　　　　JobTracker和TaskTracker的心跳通信机制要求TaskTracker保证在1分钟之内向JobTracker汇报进展。

　　　　如果超过时间JobTracker没有收到汇报，就会将该TaskTracker从等待调度的集合中移除出去；

　　　　而如果收到任务失败的的报告，就把这个TaskTracker移动到等待调度队列尾部重新排队。但是若一个TaskTracker连续汇报了四次失败，那么也会被移出任务等待队列。

小结

　　关于故障的处理维护，一般会由专人来进行管理。

　　这部分内容就暂且不做深究了。

　　另外，为什么当一个Map节点的多个Map任务中有一个失败，其他所有Map任务都要重新执行？

　　而Reduce节点只用重新执行失败的那一个任务？

　　这个问题已在CSDN上请教网友，相信很快就有回答。