5.1 Resourcemanager 概述
❑与客户端交互，处理来自客户端的请求；
❑启动和管理ApplicationMaster，并在它运行失败时重新启动它；
❑管理NodeManager，接收来自NodeManager的资源汇报信息，并向NodeManager下达管理指令（比如杀死Container等）；
❑资源管理与调度，接收来自ApplicationMaster的资源申请请求，并为之分配资源。
5.2 Resourcemanager 内部架构
5.2 用户交互模块
5.2.1 ClientRMServiceClientRMService是一个RPC Server，为来自客户端的各种RPC请求提供服务。从实现角度看，它是一个实现了ApplicationClientProtocol协议的服务，其定义如下：
5.2.2 AdminService与ClientRMService类似，AdminService也是一个RPC Server，但它的服务对象是管理员。在YARN中，管理员列表由属性yarn.admin.acl指定（在yarn-site.xml中设置），默认情况下，属性值为“*”，表示所有用户都是管理员。从实现角度看，它是一个实现了ResourceManagerAdministrationProtocol协议的服务，其定义如下
5.3 ApplicationMaster管理
- 步骤1 用户向YARN ResourceManager提交应用程序，ResourceManager收到提交请求后，先向资源调度器申请用以启动ApplicationMaster的资源，待申请到资源后，再由ApplicationMasterLauncher与对应的NodeManager通信，从而启动应用程序的ApplicationMaster。
- 步骤2 ApplicationMaster启动完成后，ApplicationMasterLauncher会通过事件的形式，将刚刚启动的ApplicationMaster注册到AMLivelinessMonitor，以启动心跳监控。
- 步骤3 ApplicationMaster启动后，先向ApplicationMasterService注册，并将自己所在host、端口号等信息汇报给它。
- 步骤4 ApplicationMaster运行过程中，周期性地向ApplicationMasterService汇报“心跳”信息（“心跳”信息中包含想要申请的资源描述）。
- 步骤5 ApplicationMasterService每次收到ApplicationMaster的心跳信息后，将通知AMLivelinessMonitor更新该应用程序的最近汇报心跳的时间。
- 步骤6 当应用程序运行完成后，ApplicationMaster向ApplicationMasterService发送请求，注销自己。
- 步骤7 ApplicationMasterService收到注销请求后，标注应用程序运行状态为完成，同时通知AMLivelinessMonitor移除对它的心跳监控。
AM运行过程中，需要周期性地通过RPC函数ApplicationMasterProtocol#allocate与RM通信主要有以下三个作用：
❑请求资源；
❑获取新分配的资源；
❑形成周期性心跳，告诉RM自己还活着。
5.4 NodeManager管理
（1）NMLivelinessMonitor该服务周期性遍历集群中所有NodeManager，如果一个NodeManager在一定时间（可通过参数yarn.nm.liveness-monitor.expiry-interval-ms配置，默认为10min）内未汇报心跳信息，则认为它死掉了，它上面所有正在运行的Container将被置为运行失败
（2）NodesListManagerNodesListManager管理exlude（类似于黑名单）和inlude（类似于白名单）节点列表
（3）ResourceTrackerServiceResourceTrackerService实现了RPC协议ResourceTracker，负责处理来自各个NodeManager的请求，请求主要包括注册和心跳两种，
5.5 Application管理
（1）ApplicationACLsManagerApplicationACLsManager负责管理应用程序的访问权限，包含两部分权限：查看权限和修改权
（2）RMAppManagerRMAppManager负责应用程序的启动和关闭
（3）ContainerAllocationExpirer当一个AM获得一个Container后，YARN不允许AM长时间不对其使用
5.6 状态机管理
在YARN ResourceManager内部，共有4类状态机，分别是RMApp、RMAppAttempt、RMContainer和RMNode。其中，前2类状态机维护了一个应用程序相关的生命周期，包括Application生命周期、一次运行尝试的生命周期；RMContainer则维护了分配出去的各个资源的使用状态；RMNode维护了一个NodeManager（一个节点上可以有多个NodeManager）的生命周期
Application Attempt的生命周期与ApplicationMaster的生命周期基本上是一致的：一个Application内部所有任务均由ApplicationMaster维护和管理，ApplicationMaster本身需要占用一个Container，而这个Container由ResourceManager为其申请和启动。一旦ApplicationMaster成功启动，它就会与ResourceManager通信，为它内部的任务申请Container。如果ApplicationMaster重新启动，则意味着一个新的Application Attempt被启动，换句话说，一个Application Attempt的“生死存亡”与ApplicationMaster的“命运”紧紧绑定在一起。
5.6.1 RMApp状态机
RMApp是ResourceManager中用于维护一个Application生命周期的数据结构，它的实现是RMAppImpl类，该类维护了一个Application状态机，记录了一个Application可能存在的各个状态（RMAppState）以及导致状态间转换的事件（RMAppEvent）
5.6.2 RMAppAttempt状态机
5.6.3 RMContainer状态机
5.6.4 RMNode状态机
RMNode是ResourceManager中用于维护一个节点生命周期的数据结构，它的实现是RMNodeImpl类，该类维护了一个节点状态机，记录了节点可能存在的各个状态以及导致状态间转换的事件。当某个事件发生时，RMNodeImpl会根据实际情况进行节点状态转移，同时触发一个行为
5.7 几个常见行为分析
5.7.1 启动ApplicationMaster
