本文將分析Hadoop MapReduce（包括MRv1和MRv2）的兩種常見的容錯場景，***種是，作業的某個任務阻塞了，長時間占用資源不釋放，如何處理？另外一種是，作 業的Map Task全部運行完成后，在Reduce Task運行過程中，某個Map Task所在節點掛了，或者某個Map Task結果存放磁盤損壞了，該如何處理？

***種場景：作業的某個任務阻塞了，長時間占用資源不釋放，如何處理？

這種場景通常是由于軟件Bug、數據特殊性等原因導致的，會讓程序阻塞，任務運行停滯不前。在外界看來，任務（Task）好像阻塞了一樣。這種事情 經常發生，由于任務長時間占用著資源但不使用（如果不采取一定的手段，可能永遠不會被使用，造成“資源泄露”），會導致資源利用率下降，對系統不利，那 么，Hadoop MapReduce遇到這種情況如何處理呢？

在TaskTracker上，每個任務會定期向TaskTracker匯報新的進度（如果進度不變則不匯報），并由TaskTracker進一步匯 報給JobTracker。當某個任務被阻塞時，它的進度將停滯不前，此時任務不會向TaskTracker匯報進度，這樣，一定達到超時時間上 限，TaskTracker會將該任務殺掉，并將任務狀態（KILLED）匯報給JobTracker，進而觸發JobTracker重新調度該任務。

在實際應用場景中，有些正常的作業，其任務可能長時間沒有讀入或者輸出，比如讀取數據庫的Map Task或者需要連接其他外部系統的Task，對于這類應用，在編寫Mapper或Reducer時，應當啟動一個額外的線程通過Reporter組件定 期向TaskTracker匯報心跳（只是告訴TaskTracker自己還活著，不要把我殺了）。

第二種場景：作業的Map Task全部運行完成后，在Reduce Task運行過程中，某個Map Task所在節點掛了，或者Map結果存放磁盤損壞了，該如何處理？

這種場景比較復雜，需分開討論。

如果節點掛了，JobTracker通過心跳機制知道TaskTracker死掉了，會重新調度之前正在運行的Task和正在運行的作業中已經運行完成的Map Task。

如果節點沒有掛，只是存放Map Task結果的磁盤損壞了，則分兩種情況：

（1）所有的Reduce Task已經完成shuffle階段

（2）尚有部分Reduce Task沒有完成shuffle階段，需要讀取該Map Task任務

對于***種情況，如果所有Reduce Task一路順風地運行下去，則無需對已經運行完成的Map Task作任何處理，如果某些Reduce Task一段時間后運行失敗了，則處理方式與第二種一樣。

對于第二種情況，當Reduce Task遠程讀取那個已經運行完成的Map Task結果(但結果已經損壞)時，會嘗試讀取若干次，如果嘗試次數超過了某個上限值，則會通過RPC告訴所在的TaskTracker該Map Task結果已經損壞，而TaskTracker則進一步通過RPC告訴JobTracker，JobTracker收到該消息后，會重新調度該Map Task，進而重新計算生成結果。

需要強調的是，目前Hadoop MapReduce的實現中，Reduce Task重試讀取Map Task結果的時間間隔是指數形式遞增的，計算公式是10000*1.3^noFailedFetches，其中noFailedFetches取值范圍 為MAX{10， numMaps/30}，也就是說，如果map task數目是300，則需要嘗試10次才會發現Map Task結果已經損壞，嘗試時間間隔分別是10s，13s，21s，28s，37s，48s，62s，81s和106s，需要非常長的時間才能發現，而且 Map Task越多，發現時間越慢，這個地方通常需要調優，因為任務數目越多的作業，越容易出現這種問題。

在MapReduce V2.0中，所有任務（Map Task和Reduce Task）直接跟MRAppMaster交互，不需要通過類似于TaskTracker這樣的中間層，整個過程與上述過程類似，在此不再贅述，具體可閱讀書籍《Hadoop技術內幕：深入解析YARN架構設計與實現原理》中的“第8章 離線計算框架MapReduce”。