Container状态机详解(2)

p> 

p> 

p> 

p>EXITED_WITH_SUCCESS,

p> 

p>    在ContainersLauncher中，如果container正常结束并且返回值为0，则会创建CONTAINER_EXITED_WITH_SUCCESS事件，ContainerImpl调用ExitedWithSuccessTransition处理此事件，进入EXITED_WITH_SUCCESS状态。

p> 

p> 

p> 

p>KILLING,

p> 

p>    但ContainerImpl遇到KILL_CONTAINER事件时，启动清理工作，并进入KILLING状态。

p> 

p> 

p> 

p>CONTAINER_CLEANEDUP_AFTER_KILL,

p> 

p>    当ContainersLauncher准备启动一个container，但此时如果container已经处于KILLING 状态，则创建CONTAINER_KILLED_ON_REQUEST事件，ContainerImpl遇到此事件后进入CONTAINER_CLEANEDUP_AFTER_KILL状态。

p> 

p> 

p> 

p>DONE

p> 

p>ContainerImpl遇到 CONTAINER_RESOURCES_CLEANEDUP事件会进入DONE状态，即清理已经结束。

p> 

p> 

p> 

p>小结

p> 

p>    至此，ResourceManager和NodeManager相关的状态机已经分析完毕。从这些状态机我们可以看到一个作业从客户端提交到最终结束的流程，与其经历的所有状态。Yarn是在Jobtracker的基础上把作业管理功能从Jobtracker拆分出来，这使得ResourceManager处理NodeManager心跳的时间大大减少，因为它不再需要维护作业信息，而维护作业信息的Jobtracke为此需要进行许多加锁操作；另外由于作业管理已经让ApplicationMaster维护，因此可以实现自定义的ApplicationMaster已支持除MR的计算模型。代码层面上的重构最大的两点在于引入了状态机，这能很方便实现异步操作，提升ResourceManager的性能。

p> 

p>    MRApplicationMaster也包含三个状态机，分别是Job，Task，TaskAttempt，由于它不属于Yarn范畴，这里不再对它们做详细的分析，感兴趣的读者可以自行查看代码分析其状态。

p> 

p> 

p> 

p>附：ContainerImpl相关的事件产生分类：

p> 

p>public enum ContainerEventType {

p> 

p> 

p> 

p>// Producer: ContainerManager

p> 

p>INIT_CONTAINER,

p> 

p>KILL_CONTAINER,

p> 

p>UPDATE_DIAGNOSTICS_MSG,

p> 

p>CONTAINER_DONE,

p> 

p> 

p> 

p>// DownloadManager

p> 

p>CONTAINER_INITED,

p> 

p>RESOURCE_LOCALIZED,

p> 

p>RESOURCE_FAILED,

p> 

p>CONTAINER_RESOURCES_CLEANEDUP,

p> 

p> 

p> 

p>// Producer: ContainersLauncher

p> 

p>CONTAINER_LAUNCHED,

p> 

p>CONTAINER_EXITED_WITH_SUCCESS,

p> 

p>CONTAINER_EXITED_WITH_FAILURE,

p> 

p>CONTAINER_KILLED_ON_REQUEST,

p> 

p>}