聊聊RPC的拥塞控制

前言


这个话题的背景源自于Hadoop内部的底层RPC处理过程,但是笔者认为针对所有其它RPC处理场景中也会碰到类似的拥塞问题,所以可以拿出来简单讲讲。首先来解释一下这里的名词,这里的RPC拥塞指的是系统被大量的用户特定的请求堵住了,导致没办法有资源来处理其它用户的正常请求,这里我们假设请求是被扔到一个请求队列中的。这里我们姑且不讨论发起大量请求的用户操作行为是否合理,但是在这种情况下,确实使得其它RPC被堵住了。本文,我们就来讨论这个在分布式系统中经常会遇到的问题,以及对应的解决思路。

拥塞控制的解决方案


此方案思路来源于HADOOP-9640中提到的FairCallQueue的设计,更加详细的设计细节可详见此JIRA。OK,下面笔者来简单阐述下拥塞控制的解决思路。

优先级分级


我们说RPC发生拥塞现象,它实际上是一种资源请求相互影响的结果,而这个相互影响的最根本原因是我们没有对它们进行更一步的分离,而是冗余在了一起进行处理。这里首先要改进的是划分出优先级关系,每个优先级对应一个队列,比如Q0,Q1,Q3,然后定义一个规则,数字越小的,优先级越高。

队列优先级确定


队列优先级划分好之后,很重要的一个操作就是优先级的确认,在这里我们当然不会人工的设置请求的优先级,一种比较通用的,比较智能是算法是根据请求发生频率确定优先级,对于用户而言,要做的是指定这个规则,具体地来说,比如3个队列,Q1队列的请求,请求频率在0~10%之间,Q2则是10~50%ÿ

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值