文章目录
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即可。
- callqueue的实现类：
- callqueue.impl
org.apache.hadoop.ipc.FairCallQueue(默认java.util.concurrent.LinkedBlockingQueue
- RpcScheduler的实现类：
上面设置FairCallQueue之后 这个默认就是DecayRpcScheduler
- scheduler.impl
org.apache.hadoop.ipc.DecayRpcScheduler(默认org.apache.hadoop.ipc.DefaultRpcScheduler)
- 阈值：
- decay-scheduler.thresholds 长度等于优先级水平-1(默认(0.125, 0.25, 0.5))
- 优先级水平：
- scheduler.priority.levels 默认为4
- 权重：
- faircallqueue.multiplexer.weights 长度等于优先级水平的列表(默认(8,4,2,1))
- identity-provider实现类 ：
- identity-provider.impl
默认org.apache.hadoop.ipc.UserIdentityProvider
- cost-provider的实现类：
- cost-provider.impl
org.apache.hadoop.ipc.WeightedTimeCostProvider
- 计算优先级的频率：
- decay-scheduler.period-ms 默认5000