[NM 状态机2] Container状态机详解
概述
前面已经分析了RM的状态机，接下来将分析NM的状态机，NM状态机包括Container，Application，LocalizedResource三个，其中Container相对较复杂。现在我们分析Container的状态机。另外3展示了LocalizedResource的状态机图，由于其状态机比较简单，这里不再详细分析，读者可以自行查看相关代码。本文的分析基于社区Apache Hadoop最新的2.3.0版本。
NodeManager维护着本节点执行的任务（container），从图1中可以看出其维护了containerID，user，resource等信息。Container的实现类为ContainerImpl。图2展示了container的状态机。
图1 container接口
图2 Container状态机图
图3 LocalizedResource状态机图
Container状态转换与解释
NEW,
在NM中，ContainerManagerImpl实现了ContainerManagementProtocol协议，因此RM和AM可以通过RPC调用startContainers方法命令NM启动相应的Container。在NM的startContainers方法中，会创建一个ContainerImpl对象，且其状态被初始化为NEW。
LOCALIZING,
有两个地方会使ContainerImpl的状态转换为LOCALIZING。1.当ApplicationImpl初始化结束时调用AppInitDoneTransition，这时会为Application下的每个container创建ContainerEventType.INIT_CONTAINER事件，ContainerImpl处理此事件并设置自己状态为LOCALIZING（或LOCALIZED，LOCALIZATION_FAILED）。2. 但NM通过RPC调用startContainers方法命令NM启动container时，假如container对应的Application已经处于RUNNING（即初始化已经完成），这时NM会创建ContainerEventType.INIT_CONTAINER事件，ContainerImpl处理此事件并设置自己状态为LOCALIZING（或LOCALIZED，LOCALIZATION_FAILED）。
另外ContainerImpl处理INIT_CONTAINER事件时会调用RequestResourcesTransition，如果有资源需要本地化，则创建INIT_CONTAINER_RESOURCES事件并进入LOCALIZING状态；如果没有资源需要本地化，则创建LAUNCH_CONTAINER事件并进入LOCALIZED状态；如果遇到不合法的资源请求，则进入LOCALIZATION_FAILED状态。
LOCALIZED,
当需要本地化的资源都已经完成本地化后，ContainerImpl会调用LocalizedTransition，创建LAUNCH_CONTAINER事件并进入LOCALIZED状态。
LOCALIZATION_FAILED,
在本地化资源期间出现异常，则ContainerImpl调用ResourceFailedTransition处理RESOURCE_FAILED事件，清理资源后进入RESOURCE_FAILED状态。
RUNNING,
当ContainerImpl进入LOCALIZED前，都会创建LAUNCH_CONTAINER事件，此事件由ContainersLauncher负责处理，它会生成container的启动命令，设置环境变量等，然后创建CONTAINER_LAUNCHED事件并启动container进程。ContainerImpl会调用LaunchTransition处理此事件，并进入RUNNING状态。
EXITED_WITH_FAILURE,
在ContainersLauncher启动container期间出异常或container结束时返回值不为0，这时候ContainersLauncher会创建CONTAINER_EXITED_WITH_FAILURE事件，ContainerImpl调用ExitedWithFailureTransition处理此事件，进入EXITED_WITH_FAILURE状态。
EXITED_WITH_SUCCESS,
在ContainersLauncher中，如果container正常结束并且返回值为0，则会创建CONTAINER_EXITED_WITH_SUCCESS事件，ContainerImpl调用ExitedWithSuccessTransition处理此事件，进入EXITED_WITH_SUCCESS状态。
KILLING,
但ContainerImpl遇到KILL_CONTAINER事件时，启动清理工作，并进入KILLING状态。
CONTAINER_CLEANEDUP_AFTER_KILL,
当ContainersLauncher准备启动一个container，但此时如果container已经处于KILLING 状态，则创建CONTAINER_KILLED_ON_REQUEST事件，ContainerImpl遇到此事件后进入CONTAINER_CLEANEDUP_AFTER_KILL状态。
DONE
ContainerImpl遇到 CONTAINER_RESOURCES_CLEANEDUP事件会进入DONE状态，即清理已经结束。
小结
至此，ResourceManager和NodeManager相关的状态机已经分析完毕。从这些状态机我们可以看到一个作业从客户端提交到最终结束的流程，与其经历的所有状态。Yarn是在Jobtracker的基础上把作业管理功能从Jobtracker拆分出来，这使得ResourceManager处理NodeManager心跳的时间大大减少，因为它不再需要维护作业信息，而维护作业信息的Jobtracke为此需要进行许多加锁操作；另外由于作业管理已经让ApplicationMaster维护，因此可以实现自定义的ApplicationMaster已支持除MR的计算模型。代码层面上的重构最大的两点在于引入了状态机，这能很方便实现异步操作，提升ResourceManager的性能。
MRApplicationMaster也包含三个状态机，分别是Job，Task，TaskAttempt，由于它不属于Yarn范畴，这里不再对它们做详细的分析，感兴趣的读者可以自行查看代码分析其状态。
附：ContainerImpl相关的事件产生分类：
public enum ContainerEventType {
// Producer: ContainerManager
INIT_CONTAINER,
KILL_CONTAINER,
UPDATE_DIAGNOSTICS_MSG,
CONTAINER_DONE,
// DownloadManager
CONTAINER_INITED,
RESOURCE_LOCALIZED,
RESOURCE_FAILED,
CONTAINER_RESOURCES_CLEANEDUP,
// Producer: ContainersLauncher
CONTAINER_LAUNCHED,
CONTAINER_EXITED_WITH_SUCCESS,
CONTAINER_EXITED_WITH_FAILURE,
CONTAINER_KILLED_ON_REQUEST,
}
