前言

Hadoop在早期实现了一种公平调度队列取代统一大队列的模式，以此解决Hadoop RPC的拥塞控制问题。简单来理解就是防止个别“不良”用户发起的大量的RPC请求堵住正常用户的请求处理(这部分细节内容可查阅笔者之前写的相关文章：聊聊RPC的拥塞控制)。但是从后面用户对新的公平队列(FairCallQueue，以下简称FCQ)的使用过程中，又遇到了一些新的问题。本文笔者来简单聊聊这块的优化想法，结合社区对此已有的一些的讨论情况。

优化点一: FairCallQueue对于不同RPC Cost的度量优化

现有FCQ对于所有用户的请求未做区分处理，如果按照请求处理的开销来讲，就是默认每个RPC都是1个weight。但其实对于一个服务来说，write类型的RPC的处理开销要比read请求要高。一个大的write请求将block住后续所有的请求。所以从这个层面的角度来说，我们可以设定1个规则，处理1个write请求相当于处理3个读请求。此时相当于write请求的weight是3，如果read请求的weight还是按照标准1来算的话。这个层面的优化其实是RPC cost计算层的改进。

优化点二: FairCallQueue下的资源预留支持

尽管FCQ已经将队列按照优先级已经拆分出多个队列来保证每个队列都能够得到及时的处理。但是有的时候，还是有可能会遇到关键用户的RPC得不到完全的保证。此时如果FCQ能够预留出特定资源给这些特定用户，对于普通用户还是落到share模式下的队列，这样FCQ将会变得更加灵活。

在预留功能支持的情况里，我们做的改动也不会很多。每次判断请求是否来自于预留用户，然后将其落入预留队列中去，后续的处理还是按照现有FCQ 加权轮询调度(WRR，Weighted Round Robin)算法来处理。

引用

[1].https://issues.apache.org/jira/browse/HDFS-14403. Cost-Based RPC FairCallQueue
[2].https://issues.apache.org/jira/browse/HADOOP-15016. RPC FairCallQueue Reservation Support