MapReduce源码分析之作业Job状态机解析（一）简介与正常流程浅析

作业Job状态机维护了MapReduce作业的整个生命周期，即从提交到运行结束的整个过程。Job状态机被封装在JobImpl中，其主要包括14种状态和19种导致状态发生的事件。

作业Job的全部状态维护在类JobStateInternal中，如下所示：

1. public enum JobStateInternal {
2. // 作业新建状态，当作业Job被新创建时所处的状态
3. NEW,
4. // 作业启动状态，此时运行时间已被设置，任务处于开始被调度阶段
5. SETUP,
6. // 作业已初始化状态，此时作业中的Map、Reduce任务均已被创建
7. INITED,
8. // 作业正在运行状态，此时作业会为Map、Reduce任务申请资源并进行资源分配，任务被启动，直至全部任务运行完成
9. RUNNING,
10. // 作业等待提交最终结果的状态，此时作业运行过程中产生的中间结果已被放置到临时目录中，当全部任务运行完成后，进行最终结果提交，即将临时目录数据提交到最终目录
11. COMMITTING,
12. // 作业运行成功状态，此时作业的运行结果被成功提交至最终目录，作业运行成功
13. SUCCEEDED,
14. // 等待正在运行的任务被杀死的状态
15. FAIL_WAIT,
16. // 作业运行失败将被注销时的状态
17. FAIL_ABORT,
18. // 作业运行失败所处的状态
19. FAILED,
20. // 作业等待被杀死时所处的状态
21. KILL_WAIT,
22. // 作业被注销时所处的状态
23. KILL_ABORT,
24. // 作业被杀死后所处的状态
25. KILLED,
26. // 作业运行过程中出错后所处的状态
27. ERROR,
28. // 作业重启所处状态
29. REBOOT
30. }

关于作业状态的详细信息，我们稍后再做介绍，这里，需要特别说明的是，前6种状态是任何一个MapReduce作业成功运行完成都必须经历的状态，而正常情况下一个作业生命周期的变化，如下图所示：

1、NEW——>INITED：由新建NEW状态到已初始化INITED状态

MRAppMaster中作业Job被创建时处于NEW状态，然后MRAppMaster会接着生成一个JOB_INIT事件，交给作业事件分发器jobEventDispatcher处理，如上图所示，实际上就是通过JobImpl中的InitTransition处理，此时作业会由NEW状态转换成INITED状态，当然如果初始化失败作业还是会停留在新建NEW状态；

2、INITED——>SETUP：由已初始化INITED状态到启动SETUP状态

MRAppMaster中等到作业初始化后，即为INITED状态时，MRAppMaster会生成一个JobStartEvent事件，其事件类型为JOB_START，交给事件分发器dispatcher（也就是作业事件分发器jobEventDispatcher）处理，实际上也是通过JobImpl中的StartTransition处理，在其transition()方法内处理完毕后，作业会由已初始化INITED状态转换成启动SETUP状态；

3、SETUP——>RUNNING：由启动SETUP状态到作业正在运行RUNNING状态

在上述StartTransition的transition()方法最后，会生成一个CommitterJobSetupEvent事件并提交给事件分发器dispatcher处理，而CommitterJobSetupEvent事件的类型是JOB_SETUP，其会被交由CommitterEventHandler组件处理，在其内部EventProcessor的handleJobSetup()方法中，针对JOB_SETUP事件处理的方式就是提交一个类型为JOB_SETUP_COMPLETED的JobSetupCompletedEvent事件，也就是上图的JOB_SETUP_COMPLETED，然后就会被交给SetupCompletedTransition处理，其内部会调度Task进行资源申请和分配，并启动相关任务运行，此时Job就会由由启动SETUP状态转换到作业正在运行RUNNING状态；

4、RUNNING——>RUNNING：由作业正在运行RUNNING状态到作业正在运行RUNNING状态

4.1、作业任务运行尝试完成事件JOB_TASK_ATTEMPT_COMPLETED不会导致作业的状态改变；

4.2、作业任务运行完成事件JOB_TASK_COMPLETED，则会在TaskCompletedTransition的transition()方法中，根据作业中任务的整体完成情况，确定作业状态的过渡，比如：

4.2.1、如果作业中任务失败数目，不管是Map还是Reduce任务，超过一定的比例，而作业任务均已完成（或成功或失败），则会将作业状态过渡到FAIL_ABORT状态，并提交CommitterJobAbortEvent事件处理，否则如果任务还尚未全部完成，则会过渡到FAIL_WAIT状态；

4.2.2、如果作业完成数目满足要求，则会将作业状态过渡到COMMITTING状态，否则还是停留在RUNNING状态，等待其他任务完成时再判断；

4.3、作业运行完成事件JOB_COMPLETED也是会通过类似4.2对作业中整体情况进行判断，确定作业运行状态是应该停留在RUNNING状态，还是应该过渡到COMMITTING状态，这个是在JobNoTasksCompletedTransition的transition()方法中进行判断的。

5、RUNNING——>COMMITTING：由作业正在运行RUNNING状态到作业等待提交最终结果COMMITTING状态

由JOB_TASK_COMPLETED和JOB_COMPLETED事件触发，具体参加上述4的分析，这里不再赘述；

6、COMMITTING——>SUCCEEDED：由作业等待提交最终结果COMMITTING状态到作业成功状态

由JOB_COMMIT_COMPLETED事件触发，并由CommitSucceededTransition处理，详情以后再做分析。

关于作业状态机的全部过渡流程，及每两个状态过渡的细节，请关注后续文章！