YARN中MRAppMaster的事件驱动模型与状态机处理消息过程的分析

在MRv1中，对象之间的作用关系是基于函数调用实现的，当一个对象向另外一个对象传递消息时，会直接采用函数调用的方式，并且这个过程是串行的。比如，当TaskTracker需要执行一个Task的时候，将首先下载Task依赖的文件(JAR包，二进制文件等，字典文件等)，然后执行Task。在整个过程中，下载依赖文件是阻塞式的，也就是说，前一个任务未完成文件下载之前，后一个新任务将一直处于等待状态，只有在下载完成之后，才会启动一个独立进程运行该任务。基于函数调用式的编程模型是低效的，它隐含着整个过程是串行，同步进行的。

相比之下，MRv2引入的时间驱动变成模型则是一种更加高效的方式。在基于事件驱动的编程模型中，所有对象被抽象成了事件处理器，而事件处理器之间通过事件相互关联。每种事件处理一种类型的事件，同时根据需要出发另外一种事件。相比于基于函数调用的编程模型，这种编程方式具有异步并发等特点，更加高效，更加适合大型分布式系统。

下面，我们以负责控制MapReduce作业的AppllicationMaster，也就是MRAppMaster为例，看一下整个事件驱动模型与状态机。

首先，根据源代码，我们可以看到在MRAppMaster中有一个最重要的中央异步消息调度器 AsyncDispatcher，它负责整个MRAppMaster模块的消息调度。除此之外，还有多个其他的消息调度器，比如 JobEventDispatcher， TaskEventDispatcher，TaskAttemptEventDispatcher，SpeculatorEventDispatcher 等等。在MRAppMaster的初始时，在serviceInit() 函数中有以下关键代码

this.jobEventDispatcher = new JobEventDispatcher();
//register the event dispatchers
dispatcher.register(JobEventType.class, jobEventDispatcher);
dispatcher.register(TaskEventType.class, new TaskEventDispatcher());
dispatcher.register(TaskAttemptEventType.class, new TaskAttemptEventDispatcher());
dispatcher.register(CommitterEventType.class, committerEventHandler);

这里的意思是，当中央消息调度器dispatcher如果收到JobEventType的消息后，将会把这个消息转发给名为jobEventDispatcher的JobEventDispatcher的消息调度器。这个JobEventDispatcher是专门用来处理JobEventType事件的消息处理器。底层实现其实就是将一个pair<JobEventType.class, JobEventDispatcher>这个KV放入中央消息调度器dispatcher的HashMap中。剩下的几个消息调度器一样，注册相应的消息类型和其相对应的消息调度器。

之后dispatcher启动一个处理消息线程，可以在下面代码看到中央消息处理器处理消息。

  Runnable createThread() {
    return new Runnable() {
      @Override
      public void run() {
        while (!stopped && !Thread.currentThread().isInterrupted()) {
          Event event;
          try {
            event = eventQueue.take();   // 从中央消息处理器dispatcher的消息队列中获得消息
          } catch(InterruptedException ie) {
            if (!stopped) {
              LOG.warn("AsyncDispatcher thread interrupted", ie);
            }
            ret