前言
在YARN早期的队列分配策略中，系统采用的是相对直接简单的办法：按照相对使用率选择。简单地来说，就是选择相对使用率最低的队列，然后把应用提交那个队列上。但是这种简单直接的做法，有的时候也会暴露出它的弊端。本文笔者来聊聊这个话题以及对应的一个优化分配策略。
按相对使用率分配的弊端
在旧的分配策略中，也就是按照队列使用率来分配的策略中，会有什么弊端呢？表面上来看，这种策略十分合理啊。其实呢，这里最大的一个问题是会导致资源碎片的问题。资源碎片的产生，就不利于大任务资源块的分配。下面通过一个例子，来具体描述一下这个问题。
假设现在我们有2个队列Service（重要任务）队列和Batch（短时间批任务）队列，3个节点，每个节点内存100GB，总共100GB*3=300GB资源，Service队列资源配比集群资源的2/3，Batch则为1/3。
假设此时两个队列资源使用情况已如下图所示
然后Service队列还有一个90G的资源请求，而Batch队列还有一个20G的资源请求。那么问题来了，谁会有机会使用Node2资源呢?按照常理，我们想，应该是90G的资源请求，这样使用率会更高一些。
答案其实不是这样的，按照相对使用率算法，Service队列使用率90/200=0.45，B则是20/100=0.2<0.45，所以系统资源优先分配给Batch队列请求。分配后的结果图如下（下图Node2的20G应该显示黄颜色的）。
其实我们可以看出，后面的90G的请求资源怎么都处理不了了，因为没有这么大的节点空间资源了。反之，如果先分配掉90G资源，系统还是有机会处理20G资源请求的。这里就是上文提到的按照相对使用率，导致资源碎片的问题，进而导致大资源请求无法被处理。
队列优先级分配策略
基于上面提到的问题，社区提出了队列优先级的概念，并且可以以此作为判定条件的分配策略。当所有队列的优先级都相等时，就等价于原来的分配算法了。相当于来说，先看优先级，优先级一致，再看相对使用率。总体来说，这样的分配策略，会显得更加灵活一些。
下面我们来看看队列优先级分配策略具体是怎样的。
首先，队列按照树型结构，每个队列给它分配上优先级值，0，1，2.。。。数字越高，表明优先级越大。如下图。
假设说，刚刚那个例子，Batch队列对应的是D队列，Service队列对应的是H队列，此时2个队列都有等待被处理的请求，那么在使用队列优先级的情况下，我们遵循的原则如下：
- 当2个队列的优先级不同，这里还分为2个情况：
- 共享同一个父亲节点时，2个优先级不同。
- 不属于同个父亲节点，则寻找它们的最近公共祖先，比较公共祖先下的2个孩子节点的优先级。
- 2个队列优先级相同（祖先节点优先级都相同），等价于传统方式的比较，根据资源相对使用率做为判定标准。
在上面的例子中，D，H队列的比较实则是A下的节点B和C节点的比较，因为C队列的优先级比B高，所以我们优先处理H队列的请求。
从这里我们来仔细理解这个分配策略，它通过给队列带上优先级属性，使得请求资源某种程度上具有偏向性，更重要的队列的应用请求能够被优先地处理。大家可以细细体会这个优先级分配策略的奥妙之处。
参考资料
[1].https://issues.apache.org/jira/browse/YARN-5864. YARN Capacity Scheduler - Queue Priorities