HDFS RBF模式RPC吞吐量瓶颈的优化探索

前言

---

之前笔者介绍过HDFS的RBF方案来解决HDFS NameNode单点瓶颈的问题。目前也是有越来有多的公司采用RBF的方案来做HDFS集群的统一管理。笔者在最近一段时间也是在调研RBF的特性同时也是测测这里面还有没有一些没有被发现的问题。在此期间，我和同事小伙伴发现里面最大的一个问题：上了RBF后，RPC的上限吞吐量比之前直连NN时降了非常之多。之前直连NN测试时，我们可以压到30k+的水准，在RBF模式下，这个数字只能到26.7k的样子。这里面性能差距在10%~20%之间。后续我们一直在尝试找里面的原因，最后发现是由于Sasl的加解密阶段导致的性能开销。但这其中的排查过程并不是那么简单，本文笔者就来聊聊这个问题的排查过程。

RBF模式的RPC吞吐量问题原因猜想

---

在RBF模式下，用户面对的直接服务是Router服务，而不是NN。所以用户的RPC请求，首先经过的是Router，然后再由Router转发到NN上去。简单来说，在RBF模式下，RPC的整个调用链路长了很多。这样很自然我们会有一种猜想：是否就是因为多了这一步的RPC请求转发，造成的RPC吞吐量的影响呢？

当然上面这个猜想说的还不是很具体，Router的这边的处理其实包含了许多细节的操作，里面每一中具体操作的延时都可能造成RPC的影响。这里如果展开来讨论的话，大致会有以下几类情况：

• Router的请求转发的网络延时造成的RPC吞吐量的下降(上面提到的这个猜想)。
• Router服务本身对RPC的处理造成的影响，比如Router做路径解析，构建connection等等操作。
• Router和NameNode之间的通信问题，增加RPC的开销。另外，这里也可能是NN的问题，比如下游NameNode callqueue被打满了导致处理的变慢。

下面我们逐一对上面的原因猜想做验证。

网络延时的影响

---

测试Router到NN的网络延时，办法很简单，登录Router，用ping命令测从Router到目标NN的网络延时。通过Ping命令，我们还能看到这过程里面是否存在丢包的情况。

后来，通过ping命令的测试，我们内部的Router到NN的延时只有0.01毫秒，这里面的延时基本上是可以忽略的。

Router本身服务处理的影响