资源调度器（ResourceScheduler）是yarn的一个非常核心的组件，它负责将各个节点上的资源封装成container，并按照一定的约束条件（按队列分配，每个队列有一定的资源分配上限等），分配给各个application。yarn的资源管理器实际上是一个事件处理器，它需要处理来自外部6中SchedulerEvent类型的事件，并根据时间的具体含义进行处理，
NODE_REMOVED
事件NODE_REMOVED表示集群中被移除一个计算节点（可能是节点故障或者管理员主动移除），资源调度器收到该事件时需要从可分配资源总量中移除相应的资源量。NODE_ADDED
事件NODE_ADDED表示集群中增加了一个计算节点，资源调度器收到该事件时需要将新增的资源量添加到可分配资源总量中。APPLICATION_ADDED
事件APPLICATION_ADDED 表示ResourceManager收到一个新的Application。通常而言，资源管理器需要为每个application维护一个独立的数据结构，以便于统一管理和资源分配。资源管理器需将该Application添加到相应的数据结构中。APPLICATION_REMOVED
事件APPLICATION_REMOVED表示一个Application运行结束（可能成功或者失败），资源管理器需将该Application从相应的数据结构中清除。CONTAINER_EXPIRED
当资源调度器将一个container分配给某个ApplicationMaster后，如果该ApplicationMaster在一定时间间隔内没有使用该container，则资源调度器会对该container进行再分配。NODE_UPDATE
NodeManager通过心跳机制向ResourceManager汇报各个container运行情况，会触发一个NODE_UDDATE事件，由于此时可能有新的container得到释放，因此该事件会触发资源分配，也就是说，该事件是6个事件中最重要的事件，它会触发资源调度器最核心的资源分配机制。
资源表示模型
当前YARN支持内存和CPU两种资源类型的管理和分配。当NodeManager启动时，会向ResourceManager注册，而注册信息中会包含该节点可分配的CPU和内存总量，这两个值均可通过配置选项设置，具体如下：
yarn.nodemanager.resource.memory-mb 表示该节点上YARN可使用的物理内存总量，默认是8192（MB），注意，如果你的节点内存资源不够8GB，则需要调减小这个值，而YARN不会智能的探测节点的物理内存总量。
yarn.nodemanager.vmem-pmem-ratio 任务每使用1MB物理内存，最多可使用虚拟内存量，默认是2.1。
yarn.nodemanager.pmem-check-enabled
是否启动一个线程检查每个任务正使用的物理内存量，如果任务超出分配值，则直接将其杀掉，默认是true。
yarn.nodemanager.vmem-check-enabled
是否启动一个线程检查每个任务正使用的虚拟内存量，如果任务超出分配值，则直接将其杀掉，默认是true。
yarn.scheduler.minimum-allocation-mb
单个任务可申请的最少物理内存量，默认是1024（MB），如果一个任务申请的物理内存量少于该值，则该对应的值改为这个数。
yarn.scheduler.maximum-allocation-mb
单个任务可申请的最多物理内存量，默认是8192（MB）。
这里讲下对虚拟内存的监控：
NodeManager 接收到 AppMaster 传递过来的 Container 后，会用 Container 的物理内存大小 (pmem) * yarn.nodemanager.vmem-pmem-ratio 得到 Container 的虚拟内存大小的限制，
然后，NodeManager 在 monitor 线程中监控 Container 的 pmem（物理内存）和 vmem（虚拟内存）的使用情况。如果当前 vmem 大于 vmemLimit 的限制，或者 olderThanAge（与 JVM 内存分代相关）的内存大于限制，则 kill 掉进程：
f (currentMemUsage > (2 * vmemLimit)) {
isOverLimit = true;
} else if (curMemUsageOfAgedProcesses > vmemLimit) {
isOverLimit = true;
if (isMemoryOverLimit) {
// kill the container
eventDispatcher.getEventHandler().handle(new ContainerKillEvent(containerId, msg));
}
这里的 vmem 究竟是不是 OS 层面的虚拟内存概念呢？
ContainerMontor 就是上述所说的 NodeManager 中监控每个 Container 内存使用情况的 monitor，它是一个独立线程。ContainerMonitor 获得单个 Container 内存（包括物理内存和虚拟内存）使用情况的逻辑如下:
Monitor 每隔 3 秒钟就更新一次每个 Container 的使用情况；更新的方式是：
查看 /proc/pid/stat 目录下的所有文件，从中获得每个进程的所有信息；
根据当前 Container 的 pid 找出其所有的子进程，并返回这个 Container 为根节点，子进程为叶节点的进程树；在 Linux 系统下，这个进程树保存在 ProcfsBasedProcessTree 类对象中；
然后从 ProcfsBasedProcessTree 类对象中获得当前进程 (Container) 总虚拟内存量和物理内存量。
因此，内存量是通过 /proc/pid/stat 文件获得的，且获得的是该进程及其所有子进程的内存量。所以，这里的 vmem 就是 OS 层面的虚拟内存概念。
yarn默认yarn.nodemanager.vmem-check-enabled 开启检测一个线程检查每个任务正使用的虚拟内存量VmemLimit，如果任务超出分配值，则直接将其杀掉.
YARN对内存资源和CPU资源采用了不同的资源隔离方案，对于CPU资源，则采用了Cgroups进行资源隔离。Linux CGroup全称Linux Control Group， 是Linux内核的一个功能，用来限制，控制与分离一个进程组群的资源（如CPU、内存、磁盘输入输出等）。这个项目最早是由Google的工程师在2006年发起，最早的名称为进程容器（process containers）。在2007年时，因为在Linux内核中，容器（container）这个名词太过广泛，为避免混乱，被重命名为cgroup，并且被合并到2.6.24版的内核中去。Cgroup是Linux 在内核中以文件系统的形式为我们实现的一种资源隔离的机制。位于 /sys/fs/cgroup 目录 。它用来限制，控制一个进程群组的资源。工作方式类似于：先对计算机的某个资源设置了一些限制规则，如只能使用 CPU 的20%。然后，如果我们想一些进程去遵守这个使用 CPU 资源的限制的话，就将它加入到这个规则所绑定的进程组中，之后，相应的限制就会对其生效。总的来说，使用 CGroup，可以以控制组为单位，对其使用的操作系统的资源做更精细的控制。一个控制组包含多个进程，而资源的限制也是定义在控制组上的。若一个进程加入到某一个控制组，则自动会受到定义在这个控制组上面的限制规则的影响。
先来看下 cgroup 的文件系统下都提供了对那些资源的隔离：
xr@xr-lab:/sys/fs/cgroup$ ll
total 0
drwxr-xr-x 15 root root 380 10月 24 14:35 ./
drwxr-xr-x 11 root root 0 10月 24 19:33 ../
dr-xr-xr-x 4 root root 0 10月 24 19:33 blkio/
lrwxrwxrwx 1 root root 11 10月 24 14:35 cpu -> cpu,cpuacct/
lrwxrwxrwx 1 root root 11 10月 24 14:35 cpuacct -> cpu,cpuacct/
dr-xr-xr-x 5 root root 0 10月 24 19:39 cpu,cpuacct/
dr-xr-xr-x 2 root root 0 10月 24 19:33 cpuset/
dr-xr-xr-x 4 root root 0 10月 24 19:33 devices/
dr-xr-xr-x 4 root root 0 10月 24 19:33 memory/
lrwxrwxrwx 1 root root 16 10月 24 14:35 net_cls -> net_cls,net_prio/
dr-xr-xr-x 2 root root 0 10月 24 19:33 net_cls,net_prio/
lrwxrwxrwx 1 root root 16 10月 24 14:35 net_prio -> net_cls,net_prio/
dr-xr-xr-x 2 root root 0 10月 24 19:33 perf_event/
dr-xr-xr-x 4 root root 0 10月 24 19:33 pids/
dr-xr-xr-x 2 root root 0 10月 24 19:33 rdma/
dr-xr-xr-x 5 root root 0 10月 24 19:33 systemd/
dr-xr-xr-x 5 root root 0 10月 24 19:33 unified/
其中 cpu 和 memory 我们都是比较熟悉的，而 blkio 代表了用于 I/O 的块设备，姑且可以将它当做是硬盘资源吧。假设我们现在有一个核心逻辑为「死循环」的程序:
int main(void)
{
int i = 0;
for(;;) i++;
return 0;
}
启动了该程序后，可以通过 top命令看到其 CPU 占用率已经到达了100%。然后，我们这前不是在/sys/fs/cgroup/cpu下创建了一个haoel的group。我们先设置一下这个group的cpu利用的限制：
hchen@ubuntu:~# cat /sys/fs/cgroup/cpu/haoel/cpu.cfs_quota_us
-1
root@ubuntu:~# echo 20000 > /sys/fs/cgroup/cpu/haoel/cpu.cfs_quota_us
我们看到，这个进程的PID是3529，我们把这个进程加到这个cgroup中：
# echo 3529 >> /sys/fs/cgroup/cpu/haoel/tasks
然后，就会在top中看到CPU的利用立马下降成20%了。（前面我们设置的20000就是20%的意思）
我们继续改造一下这个小程序：
- 父进程启动后且创建子进程之前在 /sys/fs/cgroup/cpu 目录下再新建一个目录，作为一个我们自定义的进程组。并且对这个进程组使用的 CPU 资源写入一个限制规则：只能使用 CPU 的50%
- 创建一个子进程并将其加入到我们已经创建好的进程组中，然后执行「死循环」逻辑
#include
#include
#include
#include
#include
#include
#include
#include
#include
#define STACK_SIZE (1024 * 1024)
int pipefd[2];
static char container_stack[STACK_SIZE];
int container_main(void* arg)
{
char ch;
int i = 0;
close(pipefd[1]);
read(pipefd[0], &ch, 1);
printf("start\n");
for(;;)i++;
return 1;
}
int main()
{
printf("Parent - start a container!\n");
/* 设置CPU利用率为50% */
mkdir("/sys/fs/cgroup/cpu/deadloop", 755);
system("echo 50000 > /sys/fs/cgroup/cpu/deadloop/cpu.cfs_quota_us");
pipe(pipefd);
/* 调用clone函数，其中传出一个函数，还有一个栈空间的（为什么传尾指针，因为栈是反着的） */
int container_pid = clone(container_main, container_stack+STACK_SIZE, SIGCHLD ,NULL);
char cmd[128];
sprintf(cmd, "echo %d >> /sys/fs/cgroup/cpu/deadloop/tasks",container_pid);
system(cmd);
close(pipefd[1]);
waitpid(container_pid, NULL, 0);
printf("Parent - container stopped!\n");
return 0;
}
使用了一个 pipe 做父子进程间的同步，确保父进程把子进程 id 写入到名为 deadloop 的进程组之后再唤醒子进程执行死循环的逻辑。编译执行后，可以通过 top 命令看到，子进程的 CPU 利用率已经被限制到了50%。除了对 CPU 限制之外，对 MEM，硬盘容量都可以做限制，甚至对某个块设备的读写速率也是可以限制的。
在yarn中为了更细粒度的划分CPU资源，YARN将每个物理CPU划分成若干个虚拟CPU，用户提交应用程序时，需指定每个任务需要的虚拟CPU个数，该值默认为2。
YARN对内存资源和CPU资源采用了不同的资源隔离方案。对于内存资源，为了能够更灵活的控制内存使用量，YARN采用了进程监控的方案控制内存使用，即每个NodeManager会启动一个额外监控线程监控每个container内存资源使用量，一旦发现它超过约定的资源量，则会将其杀死。对cpu则采用linux内核提供的cgourp功能。
资源分配模型
在YARN中，用户以队列的形式组织，每个用户可属于一个或多个队列，且只能向这些队列中提交application。每个队列被划分了一定比例的资源。
YARN的资源分配过程是异步的，也就是说，资源调度器将资源分配给一个application后，它不会立刻push给对应的ApplicaitonMaster，而是暂时放到一个缓冲区中，等待ApplicationMaster通过周期性的RPC函数主动来取，也就是说，采用了pull-based模型。
同MRv1一样，YARN也自带了三种常用的调度器，分别是FIFO，Capacity Scheduler和Fair Scheduler，其中，第一个是默认的调度器，它属于批处理调度器，而后两个属于多租户调度器，它采用树形多队列的形式组织资源，更适合公司应用场景。这三种调度器采用的算法与MRv1中的完全一致。
- FIFO Scheduler把应用按提交的顺序排成一个队列，这是一个先进先出队列，在进行资源分配的时候，先给队列中最头上的应用进行分配资源，待最头上的应用需求满足后再给下一个分配，以此类推。
FIFO Scheduler是最简单也是最容易理解的调度器，也不需要任何配置，但它并不适用于共享集群。大的应用可能会占用所有集群资源，这就导致其它应用被阻塞。在共享集群中，更适合采用Capacity Scheduler或Fair Scheduler，这两个调度器都允许大任务和小任务在提交的同时获得一定的系统资源。
在FIFO 调度器中，小任务会被大任务阻塞。对于Capacity调度器，有一个专门的队列用来运行小任务，但是为小任务专门设置一个队列会预先占用一定的集群资源，这就导致大任务的执行时间会落后于使用FIFO调度器时的时间。
在Fair调度器中，我们不需要预先占用一定的系统资源，Fair调度器会为所有运行的job动态的调整系统资源。当第一个大job提交时，只有这一个job在运行，此时它获得了所有集群资源；当第二个小任务提交后，Fair调度器会分配一半资源给这个小任务，让这两个任务公平的共享集群资源。
需要注意的是，从第二个任务提交到获得资源会有一定的延迟，因为它需要等待第一个任务释放占用的Container。小任务执行完成之后也会释放自己占用的资源，大任务又获得了全部的系统资源。最终的效果就是Fair调度器即得到了高的资源利用率又能保证小任务及时完成。
Capacity Scheduler 容器调度
Capacity 调度器允许多个组织共享整个集群，每个组织可以获得集群的一部分计算能力。通过为每个组织分配专门的队列，然后再为每个队列分配一定的集群资源，这样整个集群就可以通过设置多个队列的方式给多个组织提供服务了。除此之外，队列内部又可以垂直划分，这样一个组织内部的多个成员就可以共享这个队列资源了，在一个队列内部，资源的调度是采用的是先进先出(FIFO)策略。
通常一个job可能使用不了整个队列的资源。然而如果这个队列中运行多个job，如果这个队列的资源够用，那么就分配给这些job，如果这个队列的资源不够用了呢？其实Capacity调度器仍可能分配额外的资源给这个队列，这就是“弹性队列”(queue elasticity)的概念。在正常的操作中，Capacity调度器不会强制释放Container，当一个队列资源不够用时，这个队列只能获得其它队列释放后的Container资源。当然，我们可以为队列设置一个最大资源使用量，以免这个队列过多的占用空闲资源，导致其它队列无法使用这些空闲资源，这就是”弹性队列”需要权衡的地方。
假设我们有如下层次的队列：
root
├── prod
└── dev
├── eng
└── science
下面是一个简单的Capacity调度器的配置文件，文件名为capacity-scheduler.xml。在这个配置中，在root队列下面定义了两个子队列prod和dev，分别占40%和60%的容量。需要注意，一个队列的配置是通过属性yarn.sheduler.capacity.
我们可以看到，dev队列又被分成了eng和science两个相同容量的子队列。dev的maximum-capacity属性被设置成了75%，所以即使prod队列完全空闲dev也不会占用全部集群资源，也就是说，prod队列仍有25%的可用资源用来应急。我们注意到，eng和science两个队列没有设置maximum-capacity属性，也就是说eng或science队列中的job可能会用到整个dev队列的所有资源（最多为集群的75%）。而类似的，prod由于没有设置maximum-capacity属性，它有可能会占用集群全部资源。
Capacity容器除了可以配置队列及其容量外，我们还可以配置一个用户或应用可以分配的最大资源数量、可以同时运行多少应用、队列的ACL认证等。
队列的设置
关于队列的设置，这取决于我们具体的应用。比如，在MapReduce中，我们可以通过mapreduce.job.queuename属性指定要用的队列。如果队列不存在，我们在提交任务时就会收到错误。如果我们没有定义任何队列，所有的应用将会放在一个default队列中。注意：对于Capacity调度器，我们的队列名必须是队列树中的最后一部分，如果我们使用队列树则不会被识别。比如，在上面配置中，我们使用prod和eng作为队列名是可以的，但是如果我们用root.dev.eng或者dev.eng是无效的。
Fair Scheduler（公平调度器）的配置
Fair调度器的设计目标是为所有的应用分配公平的资源，举个例子，假设有两个用户A和B，他们分别拥有一个队列。当A启动一个job而B没有任务时，A会获得全部集群资源；当B启动一个job后，A的job会继续运行，不过一会儿之后两个任务会各自获得一半的集群资源。如果此时B再启动第二个job并且其它job还在运行，则它将会和B的第一个job共享B这个队列的资源，也就是B的两个job会用于四分之一的集群资源，而A的job仍然用于集群一半的资源，结果就是资源最终在两个用户之间平等的共享。
调度器的使用是通过yarn-site.xml配置文件中的yarn.resourcemanager.scheduler.class参数进行配置的，默认采用Capacity Scheduler调度器。如果我们要使用Fair调度器，需要在这个参数上配置FairScheduler类的全限定名： org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler。
队列的层次是通过嵌套
Fair调度器中的队列有一个权重属性（这个权重就是对公平的定义），并把这个属性作为公平调度的依据。在这个例子中，当调度器分配集群40:60资源给prod和dev时便视作公平，eng和science队列没有定义权重，则会被平均分配。这里的权重并不是百分比，我们把上面的40和60分别替换成2和3，效果也是一样的。注意，对于在没有配置文件时按用户自动创建的队列，它们仍有权重并且权重值为1
每个队列内部仍可以有不同的调度策略。队列的默认调度策略可以通过顶级元素
抢占（Preemption）
当一个job提交到一个繁忙集群中的空队列时，job并不会马上执行，而是阻塞直到正在运行的job释放系统资源。为了使提交job的执行时间更具预测性（可以设置等待的超时时间），Fair调度器支持抢占。
抢占就是允许调度器杀掉占用超过其应占份额资源队列的containers，这些containers资源便可被分配到应该享有这些份额资源的队列中。需要注意抢占会降低集群的执行效率，因为被终止的containers需要被重新执行。
可以通过设置一个全局的参数yarn.scheduler.fair.preemption=true来启用抢占功能。此外，还有两个参数用来控制抢占的过期时间（这两个参数默认没有配置，需要至少配置一个来允许抢占Container）：
minimum share preemption timeout
- fair share preemption timeout
如果队列在minimum share preemption timeout指定的时间内未获得最小的资源保障，调度器就会抢占containers。我们可以通过配置文件中的顶级元素