AM容错

 董博客上的题，问题2：修改ResourceManager和资源调度器相关实现，使其支持以下容错机制：当一个应用程序的ApplicationMaster运行失败时，先尝试在原节点重启它，如果重启失败，再将其重新调度到其他节点上。

想回答这个问题，强迫自己看了很久相关的代码流程。有了自己的一个思路，现在也只是记录下来不知道可行性如何。

您好，第二题不知道按下面思路可不可以实现，先分析失败原因，ApplicationManster运行失败发生在下面三种情况：第一种情况RMAppAttempt处于状态Allocated，当AMLauncher在处理LAUNCH类型事件失败时触发RMAppAttemptLaunchFailedEvent；第二种情况是RMAppAttempt处于状态Allocated，就接收到Container_FINISHED类型事件，RMAppAttemp转为失败状态；第三种是RMAppAttempt处于状态Running, 接收到Container_FINISHED类型事件做判断时发现完成的Container是masterContainer而不是正常的Container，RMAppAttempt转为失败状态。
   针对上面ApplicationMaster失败的三种情况，有一个共同点均会调用BaseFinalTransition触发RMAppFailed事件,当RMApp处理这个事件时，会判断是否再次启动RMAppAttempt（默认最多尝试2次，并转为RMAppState.submitted）。
   不知能否通过下面步骤实现第二题的目的，RMAppAttempt在SUBMITTED状态由于调度器发出的APP_ACCEPTED事件转向SCHEDULED状态时，ScheduleTransition中需要调用调度器的allocate方法请求一个优先级为0（AM_CONTAINER_PRIORITY）资源(Container数量为1)，在hadoop2.2源代码中allocate有两个参数一个黑名单，一个移除黑名单;通过变量applicationAttemptId可以得到ApplicationId,再通过rmContext可以得到applicationAttemptId对应的RMApp,从而得到Map<attemptId, attempt>attempts,通过获取的attempts的个数size,可以判断，如果size等于1则以前没有失败attempt,allocate不做任何改变；当size等于2说明有一次失败，则通过RMApp中attempts可以得到前一次失败的attempt,从而得到上次失败的masterContainer,从而获得失败attempt applicationmaster运行的节点nodeId(host,port),此时allocate中的黑名单加入除这个节点外其他节点，即保证在原节点启动ApplicationMaster;如果attempts size等于3 则说明已经在同一个节点失败两次，改变allocate的list参数，则把该节点加入黑名单，把其他节点移除黑名单，这样就能保证第三次applicationmaster是在其他节点请求container运行。
    当RMAttempt有Schedule状态处理CONTAINTER_ALLOCATED事件变为Allocated_saving状态时同样会调用调度器的allocate方法此时是一个空请求但会返回作为ApplciationMaster的1个container，这时修改同样的list参数还原上一步骤处理的黑名单节点。
    不知道上面的思路可不可行（发现一个问题，容量调度器allocate有黑名单功能但是公平调度器2.2的源码没有这一步骤处理）。
    利用黑名单和白名单感觉修改小，还有一种想法觉得比较通用，是在调度器中当处理NODE_UPDATE事件时以公平调度器为例如FairSchduler的AppSchedulable中assignContainer方法调用前也是通过AppSchedulable同样可以获得rmContext,以及appAttemptId变量按上面方法同样的逻辑判定此次是否允许该node分配优先级为0（AM_CONTAINER_PRIORITY）的1个container。