分布式集群下的RPC限流方案

Posted 2022-02-03 Android路上的人

文章目录

• 前言
• RPC请求限流的核心本质
• HDFS RBF架构的RPC限流方案
• 总结

前言

---

如今在大数据时代，面对如今规模数据体量快速增长的一个阶段，HDFS单集群模式已经无法支撑更加平稳高效的数据服务能力。多集群联合模式逐渐成为一种新的架构尝试，笔者所在公司亦是如此。我们内部目前采用了社区的RBF（Router-based Federation ）方案来做统一的数据服务。最近我们在尝试解决一个棘手的问题：多用户的RPC请求隔离问题。这个问题其实在原始HDFS单集群模式本身也是存在的，但是在多集群模式下这个问题只会变得更为严重。多集群模式下，更多的用户数据被写入到集群，而这也意味着更多的用户请求将会被处理。那么这中间是可能出现一些异常的用户发送大量的请求拖慢了NameNode，导致其他正常的用户的请求处理被影响到。因此在这里，笔者想聊聊在多集群模式下如何做这种RPC请求的限流管控。

RPC请求限流的核心本质

---

限流这个词我们在日常生活中其实也经常会听到，比如手机流量用得过多了，有可能会受到一定的网络限速。但是我们平常更多的限速说的只是限制速率，但是在分布式系统中限流的概念要比限速要更宽泛一点。用一句通俗的话来解释RPC的限流：对RPC请求流量的限制。

既然我们说的是对RPC请求流量的限制，我们从限制对象的角度出发来做限制，有下面3种类型的限制方法：

• 从RPC请求的发起者做限制，就是按照用户做限制。
• 对请求操作类型做限制，就是按照操作类型做限制。
• 同时结合用户和操作类型做限制

按照用户做限制其实具体再细分又可以分成下面两种：

• 限制bad user的异常请求行为
• 保证重要用户的正常请求行为

而按照请求操作类型做限制的，规则就比较固定一点了：给定具体的限制规则，然后直接对具体某些异常操作做处理速度的限制。

当然最为理想的限流方案是能够同时限制住用户和操作的完美限流机制了。

HDFS RBF架构的RPC限流方案

---

上面小节谈了许多关于限流方法论的内容，不是特别好理解。这里笔者以一个具体的例子来展示一下实际限流方案是如何起作用的。

下图是我们内部使用RBF的多集群架构模式：

我们看到上面的服务部署是两层架构部署模式，NN（HDFS NameNode）层是实际处理请求的服务，但它不对外直接暴露给用户。用户实际访问的是Router层，Router负责接收用户请求并将请求转发给下游NN做处理。然后这里限流的逻辑也是做在Router层的。

Router在这里做了这么几个限流的措施：

• 措施一：将用户请求划分出高低优先等级。至于优先级划分的规则，这个可以按照自己实际场景来制订，比如按照最近一段时间内请求访问的频率，频率越高，优先级越低。或者说按照请求cost来做限制，请求处理开销越大，优先级越低。请求优先级的划分可以在一定程度上限制掉一些异常的RPC请求行为。
• 措施二：对于重要用户请求的额外优先处理。某些和关键SLA任务相关的“重要”的用户，他们的请求必须要能够得到足够的保障被平稳地处理。这类可以有2种简单的做法：1）让重要用户的请求直接被标记为最高优先级。2）预留出一个请求队列资源用来存放重要用户的请求。这个请求预留队列享有和最高优先级请求队列一样的处理资源。简单概括措施二的这种做法是一种保用户的做法。

因为Router层已经做了限流管控，至于底层NN端，就可以做的比较简单，这里直接划分为了Read queue和Write queue。然后NN Handler来按照权重轮询分别处理2个queue上的请求即可。

总结

---

总结概括的来说，要利用固定的一套规则做出一套通用性很好的限流方案并不是容易。如果在请求操作级别限制的很好了，那是否有时会误伤了重要用户的请求呢？如果只单方面保重要用户的请求，那么是否会出现重要用户请求打满集群的情况呢？那这时候该限不该限呢？但是如果我们假定我们的关键用户的请求确保是正常的话，那么上述笔者所讨论的这套方案还是有一定的限流效果的。以上就是本文所要简单聊聊的分布式集群下的RPC限流管控方案的内容。