一 常见容错场景分析
1.1作业某个任务阻塞了，长时间占用资源不释放
1.2在MapTask任务运行完毕，ReduceTask运行过程中，某个MapTask节点挂了，或者某个MapTask结果存放的那磁盘坏掉了
二 作业某个任务阻塞了，长时间占用资源不释放
这种问题通常是由于程序bug，数据特性造成的，会让程序阻塞，任务运行停滞不前。在我们表面上看来是任务停滞不前。
这种问题经常发生，任务长时间占用着资源不释放，如果不采取一定手段，可能会永远被占用，造成资源泄露。
在TaskTracker，每个任务会定期向TaskTracker汇报进度，如果进度不变则不汇报，这样一旦达到超时限制，TaskTracker会杀掉该任务，并将任务状态KILLED汇报给YARN,从而重新调度该任务。
在实际应用场景中，有些正常的作业，其任务可能长时间没有读入或者输出，比如读取数据库的MapTask或者需要连接其他外部系统的Task，对于这类应用，在编写Mapper或Reducer时，应当启动一个额外的线程通过Reporter组件定期向TaskTracker汇报心跳（只是告诉TaskTracker自己还活着，不要把我杀了）。
三 在MapTask任务运行完毕，ReduceTask运行过程中，某个MapTask节点挂了，或者某个MapTask结果存放的那磁盘坏掉了
Case1:如果节点挂掉，JobTracker通过心跳机制知道TaskTracker死掉了，会重新调度之前正在运行的Task和正在运行的作业中已经运行完成的MapTask
Case2:如果节点没有挂，只是存放MapTask结果的磁盘损坏了，则分两种情况
#所有的ReduceTask已经完成shuffle阶段
#尚有部分ReduceTask没有完成shuffle阶段，需要读取该MapTask任务
对于第一种情况，如果所有ReduceTask一路顺风地运行下去，则无需对已经运行完成的MapTask作任何处理，如果某些ReduceTask一段时间后运行失败了，则处理方式与第二种一样。
对于第二种情况，当ReduceTask远程读取那个已经运行完成的MapTask结果(但结果已经损坏)时，会尝试读取若干次，如果尝试次数超过了某个上限值，则会通过RPC告诉所在的TaskTracker该MapTask结果已经损坏，而TaskTracker则进一步通过RPC告诉JobTracker，JobTracker收到该消息后，会重新调度该MapTask，进而重新计算生成结果。