上一篇文章对 ResourceManager 整体架构和性能进行了讲述。本篇将对 RM 中治理 Application Master 的局部进行深刻的解说。
上面将会介绍 RM 与 AM 整体通信执行流程，并对 RM 中波及的对应服务进行具体解说。
为了更好的学习本篇常识，倡议先相熟以下知识点，不理解的局部可翻到后面对应的文章进行学习：

  • RPC（2-2 Yarn 根底库 - 底层通信库 RPC）
  • 事件处理器（2-3 Yarn 根底库 - 服务库与事件库）
  • AM 程序执行流程（3-3 Yarn Application Master 编写）

一、AM 执行流程

客户端提交工作到 RM 后，启动 AM 到工作实现的流程如下所示：

各个步骤具体执行操作请对应上面各服务解说。

二、AM 治理次要组成

ApplictionMaster 治理局部次要由三个服务形成，它们独特管理应用程序的 AM 的生存周期。
（以下服务均能依据名称找到源码中对应的类，能够看其具体的实现逻辑）

一）ApplicationMasterLauncher

  • 「服务&事件处理器」解决 AM 的 LAUNCH 和 CLEANUP 事件
  • 从源码中能够看到：EventHandler 的 handle 办法收到 AM 事件后创立 Runnable 对象，之后会放到 masterEvents 阻塞队列中，launcherHandlingThread 一直从队列中取出事件，提交到线程池 launcherPool 中解决。（流程图如下所示）

二）AMLivelinessMonitor

  • 查看服务活性（是否有心跳）
  • 继承自抽象类 AbstractLivelinessMonitor，在抽象类中曾经实现好 live 查看逻辑，在一段时间内未汇报心跳信息，则工作其挂了。AMLivelinessMonitor 只需定义当 AM 被认为挂了（expire）时，须要解决的逻辑。
  • 当失败时会发一个 RMAppAttemptEvent EXPIRE 事件。

抽象类 AbstractLivelinessMonitor 简要介绍：

public abstract class AbstractLivelinessMonitor<O> extends AbstractService {    // 外面最重要的查看函数// 定期遍历记录的 list，看是否有超时的// 查看周期默认为超时工夫的 1/3  private class PingChecker implements Runnable {    @Override    public void run() {      while (!stopped && !Thread.currentThread().isInterrupted()) {        synchronized (AbstractLivelinessMonitor.this) {          Iterator<Map.Entry<O, Long>> iterator =             running.entrySet().iterator();          //avoid calculating current time everytime in loop          long currentTime = clock.getTime();          while (iterator.hasNext()) {            Map.Entry<O, Long> entry = iterator.next();            if (currentTime > entry.getValue() + expireInterval) {              iterator.remove();              expire(entry.getKey());              LOG.info("Expired:" + entry.getKey().toString() +                       " Timed out after " + expireInterval/1000 + " secs");            }          }        }        try {          Thread.sleep(monitorInterval);        } catch (InterruptedException e) {          LOG.info(getName() + " thread interrupted");          break;        }      }    }  }

三）ApplicationMasterService

  • 是 RM RPC 服务端 ApplicationMasterProtocol 的实现类。
  • 接管解决来自 AM 的申请：次要包含注册、心跳、清理三类。

  • 心跳通过 ApplicationMasterProtocol#allocate 办法定期调用实现，次要作用：

    • 申请资源
    • 获取新调配的资源
    • 定期通知 RM 其还活着（心跳）

三、小结

本篇次要介绍了 RM 中对 AM 的治理局部。首先介绍了 RM 相干组件与 AM 交互流程，之后对各服务执行逻辑、RPC 调用等进行了具体的介绍。本篇中仅对 ApplicationMasterLauncher 组件进行了具体解说，并绘图阐明，其余部分各位同学感兴趣可自行梳理。
在学习这部分常识时，倡议对照源码进行梳理，能够更好的理解其中的流程。