HDFS之Fair Call Queue优化

Fair Call Queue

Namenode作为集群的管理角色，是RPC请求的中心，会承载来自所有客户端的RPC请求。默认的队列实现是FIFO，在这种情况下，如果某个用户的请求数量过多，可能会造成整个系统中其他所有用户的阻塞。FairCallQueue特性的出现就是为了解决该问题。

加权机制

客户端的请求会首先放入一个Listen Queue，Reader线程会将其传递给RpcScheduler，由其决定放置到Call Queue中，然后RpcMultiplexer来决定提取并处理。

==FairCallQueue的思想则是 将用户的请求划分成不同的优先级，并放入不同的优先级的队列，提取时按照不同队列的权重来处理。==这里负责的分别就是DecayRpcScheduler、FairCallQueue和WeightedRoundRobinMultiplexer。

假设：默认优先级等级是4{0,1,2,3} 默认阈值数组{0.125,0.25,0.5} 默认权重{8,4,2,1}

DecayRpcScheduler会按照可配置周期内计算用户(用户信息是通过identity provider的实现类UserIdentityProvider提供的。)的请求与总请求比例 按照大小赋予优先级

=0.5 为3，>=0.25为2，>=0.125为1，其他部分为0。并将用户和优先级存储到一个不可变的Map。

FairCallQueue会按照优先级等级，构造包含多个LinkedBlockingQueue的ArrayList。容量基本会均分，并且根据下标来对应优先级。

WeightedRoundRobinMultiplexer会定义权重，并构造一个权重数组，也是正好根据下标来对应。默认的，优先级越高的权重越多。比如，这里0优先级的权重是8，1是4，2是2，3是1。意味着，在至少15调用中，会将处理0优先级的8个请求、之后是1优先级的4次请求，依次往后。

除了优先级加权机制，还有一种可配置的回退机制。当请求要放置的队列已满时，可触发回退，默认有一种按照响应时间回退的实现。

基于Cost的扩展

这样，通过优先级和权重的设置，可以让单个用户的大量调用得到有效缓解。但是还是有一个问题，上面的实现并没有考虑请求的代价。就好比，1000次写与1000次读的代价明显是不一样的。FairCallQueue提供了一个基于cost的实现WeightedTimeCostProvider(默认是DefaultCostProvider)。它将不同锁的cost做了划分，共享锁比排他锁的cost要小。

配置

一般Namenode的端口使用8020，下面的配置项均以ipc.8020为前缀(可根据实际情况修改)。基本只设置callqueue.impl即可。

1. callqueue的实现类：

• callqueue.impl

org.apache.hadoop.ipc.FairCallQueue(默认java.util.concurrent.LinkedBlockingQueue

2. RpcScheduler的实现类：

上面设置FairCallQueue之后 这个默认就是DecayRpcScheduler

• scheduler.impl

org.apache.hadoop.ipc.DecayRpcScheduler(默认org.apache.hadoop.ipc.DefaultRpcScheduler)

3. 阈值：

• decay-scheduler.thresholds 长度等于优先级水平-1(默认(0.125, 0.25, 0.5))

4. 优先级水平：

• scheduler.priority.levels 默认为4

5. 权重：

• faircallqueue.multiplexer.weights 长度等于优先级水平的列表(默认(8,4,2,1))

6. identity-provider实现类 ：

• identity-provider.impl

默认org.apache.hadoop.ipc.UserIdentityProvider

7. cost-provider的实现类：

• cost-provider.impl

org.apache.hadoop.ipc.WeightedTimeCostProvider

8. 计算优先级的频率：

• decay-scheduler.period-ms 默认5000