资源调度器是 YARN 中最核心的组件之一，它是 ResourceManager 中的一个插拔式服务组件，负责整个集群资源的管理和分配。
Yarn 默认提供了三种可用资源调度器，分别是FIFO (First In First Out )、 Yahoo! 的 Capacity Scheduler 和 Facebook 的 Fair Scheduler。
本节会重点介绍资源调度器的基本框架，在之后文章中详细介绍 Capacity Scheduler 和 Fair Scheduler。
一、基本架构
资源调度器是最核心的组件之一，并且在 Yarn 中是可插拔的，Yarn 中定义了一套接口规范，以方便用户实现自己的调度器，同时 Yarn 中自带了FIFO，CapacitySheduler， FairScheduler三种常用资源调度器。
一）资源调度模型
Yarn 采用了双层资源调度模型。
- 第一层中，RM 中的资源调度器将资源分配给各个 AM（Scheduler 处理的部分）
- 第二层中，AM 再进一步将资源分配给它的内部任务（不是本节关注的内容）
Yarn 的资源分配过程是异步的，资源调度器将资源分配给一个应用程序后，它不会立刻 push 给对应的 AM，而是暂时放到一个缓冲区中，等待 AM 通过周期性的心跳主动来取（pull-based通信模型）
- NM 通过周期心跳汇报节点信息
- RM 为 NM 返回一个心跳应答，包括需要释放的 container 列表等信息
- RM 收到的 NM 信息触发一个NODE_UPDATED事件，之后会按照一定策略将该节点上的资源分配到各个应用，并将分配结果放到一个内存数据结构中
- AM 向 RM 发送心跳，获得最新分配的 container 资源
- AM 将收到的新 container 分配给内部任务
二）资源表示模型
NM 启动时会向 RM 注册，注册信息中包含该节点可分配的 CPU 和内存总量，这两个值均可通过配置选项设置，具体如下：
yarn.nodemanager.resource.memory-mb：可分配的物理内存总量，默认是8Gyarn.nodemanager.vmem-pmem-ratio：任务使用单位物理内存量对应最多可使用的虚拟内存，默认值是2.1，表示使用1M的物理内存，最多可以使用2.1MB的虚拟内存总量yarn.nodemanager.resource.cpu-vcores：可分配的虚拟CPU个数，默认是8。为了更细粒度地划分CPU资源和考虑到CPU性能差异，YARN允许管理员根据实际需要和CPU性能将每个物理CPU划分成若干个虚拟CPU，而管理员可为每个节点单独配置可用的虚拟CPU个数，且用户提交应用程序时，也可指定每个任务需要的虚拟CPU数
Yarn 支持的调度语义：
- 请求某个节点上的特定资源量
- 请求某个特定机架上的特定资源量
- 将某些节点加入（或移除）黑名单，不再为自己分配这些节点上的资源
- 请求归还某些资源
Yarn 不支持的调度语义（随着 Yarn 的不断迭代，可能会在未来实现）：
- 请求任意节点上的特定资源量
- 请求任意机架上的特定资源量
- 请求一组或几组符合某种特质的资源
- 超细粒度资源。比如CPU性能要求、绑定CPU等
- 动态调整Container资源，允许根据需要动态调整Container资源量
三）资源保证机制
当单个节点的闲置资源无法满足应用的一个 container 时，有两种策略：
- 放弃当前节点等待下一个节点；
- 在当前节点上预留一个 container 申请，等到节点有资源时优先满足预留。
YARN 采用了第二种增量资源分配机制（当应用程序申请的资源暂时无法保证时，为应用程序预留一个节点上的资源直到累计释放的空闲资源满足应用程序需求），这种机制会造成浪费，但不会出现饿死现象
四）层级队列管理
Yarn 的队列是层级关系，每个队列可以包含子队列，用户只能将任务提交到叶子队列。管理员可以配置每个叶子队列对应的操作系统用户和用户组，也可以配置每个队列的管理员。管理员可以杀死队列中的任何应用程序，改变任何应用的优先级等。
队列的命名用 . 来连接，比如 root.A1、root.A1.B1。
二、三种调度器
Yarn 的资源调度器是可以配置的，默认实现有三种 FIFO、CapacityScheduler、FairScheduler。
一）FIFO
FIFO 是 Hadoop设计之初提供的一个最简单的调度机制：先来先服务。
所有任务被统一提交到一个队里中，Hadoop按照提交顺序依次运行这些作业。只有等先来的应用程序资源满足后，再开始为下一个应用程序进行调度运行和分配资源。
优点：
- 原理是和实现简单。也不需要任何单独的配置
缺点：
- 无法提供 QoS，只能对所有的任务按照同一优先级处理。
- 无法适应多租户资源管理。先来的大应用程序把集群资源占满，导致其他用户的程序无法得到及时执行。
- 应用程序并发运行程度低。
二）Capacity Scheduler
Capacity Scheduler 容量调度是 Yahoo! 开发的多用户调度器，以队列为单位划分资源。
每个队列可设定一定比例的资源最低保证和使用上限。每个用户也可设置一定的资源使用上限，以防资源滥用。并支持资源共享，将队列剩余资源共享给其他队列使用。配置文件名称为 capacity-scheduler.xml。
主要特点：
- 容量保证：可为每个队列设置资源最低保证（capacity）和资源使用上限（maximum-capacity，默认100%），而所有提交到该队列的应用程序可以共享这个队列中的资源。
- 弹性调度：如果队列中的资源有剩余或者空闲，可以暂时共享给那些需要资源的队列，一旦该队列有新的应用程序需要资源运行，则其他队列释放的资源会归还给该队列，从而实现弹性灵活分配调度资源，提高系统资源利用率。
- 多租户管理：支持多用户共享集群资源和多应用程序同时运行。且可对每个用户可使用资源量（user-limit-factor）设置上限。
- 安全隔离：每个队列设置严格的ACL列表（acl_submit_applications），用以限制可以用户或者用户组可以在该队列提交应用程序。
三）Fair Scheduler
Fair Scheduler 是 Facebook 开发的多用户调度器。设计目标是为所有的应用分配「公平」的资源（对公平的定义可以通过参数来设置）。公平不仅可以在队列中的应用体现，也可以在多个队列之间工作。
在 Fair 调度器中，我们不需要预先占用一定的系统资源，Fair 调度器会为所有运行的 job 动态的调整系统资源。如下图所示，当第一个大 job 提交时，只有这一个 job 在运行，此时它获得了所有集群资源；当第二个小任务提交后，Fair 调度器会分配一半资源给这个小任务，让这两个任务公平的共享集群资源。
与Capacity Scheduler不同之处：
四）源码继承关系
看下面三个图中调度器的继承关系。这三个 Scheduler 都继承自 AbstractYarnScheduler。这个抽象类又 extends AbstractService implements ResourceScheduler。继承 AbstractService 说明是一个服务，实现 ResourceScheduler 是 scheduler 的主要功能。
三者还有一些区别，FairScheduler 没实现 Config