Application管理
YARN中,Application是指应用程序,他可能启动多个运行实例,每个运行实例由一个ApplicationMaster与一组该ApplicationMaster启动的任务组成,他拥有名称、队列名、优先级等属性,是一个比较宽泛的概念,可以是一个MapReduce作业、一个DAG应用程序，设置可以是一个Storm集群实例
(1) ApplicationACLsManager
ApplicationACLsManager负责管理应用程序的访问权限，包含两部分权限：查看权限和修改权限。其中，查看权限主要用于查看应用程序基本信息，比如运行时间、优先级等信息；而修改权限则主要用于修改应用程序优先级、杀死应用程序等。默认情况下，任意一个普通用户可以查看所有其他用户的应用程序。用户可以为自己的应用程序设置具有访问权限的用户列表，具体方法是在客户端使用ContainerLaunchContext#newInstance构造ContainerLaunchContext实例时将其作为参数传入。
通常而言，为了便于用户设置该参数，运行在YARN之上的计算框架会预留一些参数供用户提交应用程序时动态设置，比如MapReduce计算框架允许用户通过参数mapreduce.job.acl-view-job和mapreduce.job.acl-modify-job为每个应用程序设置查看和修改权限
(2) RMAppManager
RMAppManager负责应用程序的启动和关闭。ClientRMService收到来自客户端的提交应用程序请求后，将调用函数RMAppManager#submitApplication创建一个RMApp对象，它将维护这个应用程序的整个生命周期，从开始运行到最终结束；当RMApp运行结束后，将向RMAppManager发送一个RMAppManagerEventType.APP_COMPLETED事件，他收到该事件后将调用RMARMAppManager#finishApplication进行收尾工作，包括 ：
- 将该应用程序放入已完成应用程序列表中，以便用户查询历史应用程序运行信息。需要注意的是，该列表的大小是有限的，默认是10000(管理员可通过参数yarn.resourcemanager.max-completed-applications修改)，当已完成应用程序数目超过该值时，将从内存数据结构中移除(移除的应用程序可称为"过期的应用程序")，这样用户只能通过History Server获取过期的应用程序信息，History Server是从磁盘文件中获取这些信息的
- 将应用程序从RMStateStore中移除。RMStateStore记录了运行中的应用程序的运行日志，当集群故障重启后，ResourceManager可通过这些日志恢复应用程序运行状态，从而避免全部重新运行，一旦应用程序运行结束后，这些日志便失去了意义，故可以对其进行删除。这属于ResourceManager容错机制的范畴
(3) ContainerAllocationExpirer
当一个AM获得一个Container后，YARN不允许AM长时间不对其使用，因为这会降低整个集群的利用率。当AM收到RM新分配的一个Container后，必须在一定的时间内在对应的NM上启动该Container，否则RM将强制回收该Container
状态机管理
YARN中，如果一个对象由若干个状态以及触发这些状态发生转移的事件构成，它将被抽象成一个状态机，在YARN ResourceManager内部，共有四类状态机，分别是RMApp，RMAppAttempt，RMContainer和RMNode。其中，前2类状态机维护了一个应用程序相关的生命周期，包括Application生命周期，一次进行尝试的生命周期；RMContainer则维护了分配出去的各个资源的使用状态；RMNode维护了一个NodeManager的生命周期
YARN中的Application生命周期由状态机RMAppImpl维护，每个Application可能会尝试运行多次，每次成为一次"运行尝试"，而每次运行尝试的生命周期则由状态机RMAppAttemptImpl维护，如果一次运行尝试运行失败，RMApp会创建另外一个运行尝试，知道某次运行尝试运行成功或者达到运行尝试上限。对于每次运行尝试，ResourceManager将为它分配一个Container，Container是运行环境的抽象，内部封装了任务的运行环境和资源等信息，而一个应用程序的ApplicationMaster就运行在这个Container中。ApplicationMaster启动之后，会不断向ResourceManager申请Container以运行各类任务。Container的生命周期由状态机RMContainerImpl维护
Application Attempt的生命周期与ApplicationMaster的生命周期基本上是一致的 ： 一个Application内部所有任务均由ApplicationMaster维护和管理，ApplicationMaster本身需要占用一个Container，而这个Container由ResourceManager为其申请和启动。一旦ApplicationMaster成功启动，他就会与ResourceManager通信，为它内部的任务申请Container。如果ApplicationMaster重新启动，则意味着一个新的Application Attempt被启动，换句话说，一个Application Attempt的"生死存亡"与ApplicationMaster的"命运"紧紧绑定在一起