概述
Apache Hadoop 2.0在Hadoop 1.0基础上做了许多的重构工作，代码上的重构最大的变化在于引入状态机处理各个角色的状态与变迁，使用状态机是得代码结构更加清晰，方便异步处理各种操作。对于Yarn集群的维护者来说，熟悉这些状态机的流程是非常基本的要求。Hadoop 2.0当前包含十个状态机，分别是：
ResourceManager下RMApp，RMAppAttempt，RMContainer，RMNode；
NodeManager下的Application，Container，LocalizedResource；
MapReduce下的Job，Task，TaskAttempt。
笔者将在接下来的几天把Yarn相关的状态机细看一遍，并将整理整理出Yarn状态机系列文章。由于Hadoop社区非常活跃，状态机大体已经成型，不过不同版本之间还是可能存在一些区别，本系列状态机分析都是基于社区最新的release2.3.0版本分析。
本文首先介绍ResourceManager内部最复杂也是最重要的状态机——RMApp的状态机。
RMApp状态机
在RM内部，维护着所有Application的状态。对于每个Application，都有一个RMApp对象与之对应。在RMApp的实现类RMAppImpl中，维护着对象的基本信息，包括起始时间，名字，用户，组等信息，其中最复杂的部分莫过于其维护的状态机。
private static final StateMachineFactory<RMAppImpl,
RMAppState,
RMAppEventType,
RMAppEvent> stateMachineFactory
= new StateMachineFactory<RMAppImpl,
RMAppState,
RMAppEventType,
RMAppEvent>(RMAppState.NEW) // Transitions from NEW state
.addTransition(RMAppState.NEW, RMAppState.NEW,
RMAppEventType.NODE_UPDATE, new RMAppNodeUpdateTransition())
...
状态机转换如图1所示。
图1 RMApp状态转换图
状态与转换解释
NEW,
RMApp的初始状态
当客户端通过RPC调用RM的submitApplication方法后，RM会初始化RMAppImpl，此时状态机的状态被设置为NEW。
NEW_SAVING,
表示RM在处理客户端提交作业的请求期间状态为NEW_SAVING。
RM的submitApplication方法中，在返回给客户端前，RM会创建START事件，当NEW状态遇到START事件后，RMAppImpl的状态转换为NEW_SAVING。
SUBMITTED,
表示App已经提交成功，RM已经存下该App状态。两种情况下会转换为SUBMITTED状态：
1.当RMAppImpl的状态由NEW转换为NEW_SAVING期间，会触发RMAppNewlySavingTransition的transition方法，在次方法中会调用RMStateStore存储RMAppImpl，事实上是在RMStateStore.ForwardingEventHandler中调用handleStoreEvent方法存储RMAppImpl，完成存储后会调用notifyDoneStoringApplication方法，在此方法中创建RMAppNewSavedEvent事件并交给rmDispatcher。RMAppImpl遇到RMAppNewSavedEvent（对应APP_NEW_SAVED）事件后，状态转换为SUBMITTED。
2.在NEW状态下，如果是Recover模式，且改App存储在RMStateStore中，则转换为SUBMITTED。
ACCEPTED,
表示该App已经提交给调度器。
1.在NEW_SAVING转换为SUBMITTED状态的时候，RMAppImpl会触发StartAppAttemptTransition，这时会创建一个新的RMAppAttempt，然后新建RMAppAttemptEventType.START事件给处理器，经过RMAppAttempt处理机。当该RMAppAttempt交给调度器（的某个组）后，状态改为ACCEPTED。
RUNNING,
AM已经启动并注册到RM上。两种情况下会转换为RUNNING状态：
1.AM启动后会向RM注册，这时候会触发RMAppImpl状态转换为RUNNING状态。
2.RMAppImpl也有可能在Recovery模式下转换为RUNNING。
FINAL_SAVING,
FINAL_SAVING状态表示正在保存RMAppImpl到存储器，目的是保证RMAppImpl的状态已经存储下来，当RMStateStore在完成App状态更新到存储器后会根据App的状态转换为最终状态，包括FAILED，FINISHED，FINISHING，KILLED。
这个状态其实阻断了原来清晰的状态转换流程，如RUNNING在遇到RMAppEventType.ATTEMPT_FAILED时，转换为FINAL_SAVING状态，但是设置了targetedFinalState为RMAppState.FAILED，最终经过FINAL_SAVING后转换为RMAppState.FAILED状态。
FINISHING,
FINISHING状态表示RM上相应的App状态已经完成存储工作，在等待RMAppEventType.ATTEMPT_FINISHED事件。因为只有RMAppAttempt结束后RMApp才能结束。
在RMAppState.RUNNING状态遇到RMAppEventType.ATTEMPT_UNREGISTERED事件时，RMAppImpl转换为FINAL_SAVING，并存储targetedFinalState为RMAppState.FINISHING，遇到RMAppEventType.APP_UPDATE_SAVED事件后RMAppImpl转换为FINISHING状态。
FINISHED,
RMAppImpl的结束状态（另外两个个结束状态是KILLED和FAILED），正常情况下，处于RUNNING的RMAppImpl成功结束后状态就是FINISHED，另外RM收到AM的REJECTED请求后最终状态也是FINISHED，即FINISHED状态是AM主动通知RM自己结束后的状态。
FAILED,
处于FINAL_SAVING的RMAppImpl遇到RMAppEventType. FAILED事件后RMAppImpl转换为FAILED状态。
KILLING,
RMAppImpl遇到客户端执行KILL操作后会转换为FINAL_SAVING状态，另外会设置RMAppImpl的targetedFinalState为RMAppEventType.KILL。
KILLED
处于FINAL_SAVING的RMAppImpl遇到RMAppEventType.APP_UPDATE_SAVED事件后RMAppImpl转换为KILLED状态。
转载请注明出处http://www.cnblogs.com/shenh062326/p/3586510.html.
下篇文章我将详解与RMApp息息相关的RMAppAttempt状态机详解。
