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

***種場(chǎng)景：作業(yè)的某個(gè)任務(wù)阻塞了，長(zhǎng)時(shí)間占用資源不釋放，如何處理？

這種場(chǎng)景通常是由于軟件Bug、數(shù)據(jù)特殊性等原因?qū)е碌?，?huì)讓程序阻塞，任務(wù)運(yùn)行停滯不前。在外界看來(lái)，任務(wù)（Task）好像阻塞了一樣。這種事情 經(jīng)常發(fā)生，由于任務(wù)長(zhǎng)時(shí)間占用著資源但不使用（如果不采取一定的手段，可能永遠(yuǎn)不會(huì)被使用，造成“資源泄露”），會(huì)導(dǎo)致資源利用率下降，對(duì)系統(tǒng)不利，那 么，Hadoop MapReduce遇到這種情況如何處理呢？

在TaskTracker上，每個(gè)任務(wù)會(huì)定期向TaskTracker匯報(bào)新的進(jìn)度（如果進(jìn)度不變則不匯報(bào)），并由TaskTracker進(jìn)一步匯 報(bào)給JobTracker。當(dāng)某個(gè)任務(wù)被阻塞時(shí)，它的進(jìn)度將停滯不前，此時(shí)任務(wù)不會(huì)向TaskTracker匯報(bào)進(jìn)度，這樣，一定達(dá)到超時(shí)時(shí)間上 限，TaskTracker會(huì)將該任務(wù)殺掉，并將任務(wù)狀態(tài)（KILLED）匯報(bào)給JobTracker，進(jìn)而觸發(fā)JobTracker重新調(diào)度該任務(wù)。

在實(shí)際應(yīng)用場(chǎng)景中，有些正常的作業(yè)，其任務(wù)可能長(zhǎng)時(shí)間沒(méi)有讀入或者輸出，比如讀取數(shù)據(jù)庫(kù)的Map Task或者需要連接其他外部系統(tǒng)的Task，對(duì)于這類應(yīng)用，在編寫Mapper或Reducer時(shí)，應(yīng)當(dāng)啟動(dòng)一個(gè)額外的線程通過(guò)Reporter組件定 期向TaskTracker匯報(bào)心跳（只是告訴TaskTracker自己還活著，不要把我殺了）。

第二種場(chǎng)景：作業(yè)的Map Task全部運(yùn)行完成后，在Reduce Task運(yùn)行過(guò)程中，某個(gè)Map Task所在節(jié)點(diǎn)掛了，或者M(jìn)ap結(jié)果存放磁盤損壞了，該如何處理？

這種場(chǎng)景比較復(fù)雜，需分開討論。

如果節(jié)點(diǎn)掛了，JobTracker通過(guò)心跳機(jī)制知道TaskTracker死掉了，會(huì)重新調(diào)度之前正在運(yùn)行的Task和正在運(yùn)行的作業(yè)中已經(jīng)運(yùn)行完成的Map Task。

如果節(jié)點(diǎn)沒(méi)有掛，只是存放Map Task結(jié)果的磁盤損壞了，則分兩種情況：

（1）所有的Reduce Task已經(jīng)完成shuffle階段

（2）尚有部分Reduce Task沒(méi)有完成shuffle階段，需要讀取該Map Task任務(wù)

對(duì)于***種情況，如果所有Reduce Task一路順風(fēng)地運(yùn)行下去，則無(wú)需對(duì)已經(jīng)運(yùn)行完成的Map Task作任何處理，如果某些Reduce Task一段時(shí)間后運(yùn)行失敗了，則處理方式與第二種一樣。

對(duì)于第二種情況，當(dāng)Reduce Task遠(yuǎn)程讀取那個(gè)已經(jīng)運(yùn)行完成的Map Task結(jié)果(但結(jié)果已經(jīng)損壞)時(shí)，會(huì)嘗試讀取若干次，如果嘗試次數(shù)超過(guò)了某個(gè)上限值，則會(huì)通過(guò)RPC告訴所在的TaskTracker該Map Task結(jié)果已經(jīng)損壞，而TaskTracker則進(jìn)一步通過(guò)RPC告訴JobTracker，JobTracker收到該消息后，會(huì)重新調(diào)度該Map Task，進(jìn)而重新計(jì)算生成結(jié)果。

需要強(qiáng)調(diào)的是，目前Hadoop MapReduce的實(shí)現(xiàn)中，Reduce Task重試讀取Map Task結(jié)果的時(shí)間間隔是指數(shù)形式遞增的，計(jì)算公式是10000*1.3^noFailedFetches，其中noFailedFetches取值范圍 為MAX{10， numMaps/30}，也就是說(shuō)，如果map task數(shù)目是300，則需要嘗試10次才會(huì)發(fā)現(xiàn)Map Task結(jié)果已經(jīng)損壞，嘗試時(shí)間間隔分別是10s，13s，21s，28s，37s，48s，62s，81s和106s，需要非常長(zhǎng)的時(shí)間才能發(fā)現(xiàn)，而且 Map Task越多，發(fā)現(xiàn)時(shí)間越慢，這個(gè)地方通常需要調(diào)優(yōu)，因?yàn)槿蝿?wù)數(shù)目越多的作業(yè)，越容易出現(xiàn)這種問(wèn)題。

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