关于API网关(四)——限流

什么是流量限制

通俗的说,流量控制就是控制用户请求的策略,主要包括:权限、限流、流量调度。
权限上一篇已经讲过了,这一篇讲限流,下一篇讲流量调度。
限流是指限制用户调用的频率(QPS/QPM)或者次数。

为什么要有流量限制

为了收费

流量限制,站在用户或者运营的角度看,最直观能感受到的作用是——收费
各大主流开放平台的对外API,一般都有一些免费的额度,可以供个人测试用,一旦想大规模调用,就需要付费购买更大的额度(频率、次数),根据调用次数或者频率进行收费。一旦超过拥有的额度,就会被限制调用。

为了保护后面的服务

其实这才是限流最大的用处,只是用户或者运营同学无感,所以不太被大多数人了解。
网关后面是各个服务,各个服务的接口通过网关透出去给用户调用。理论上说,用户的流量是不可预知的,随时可能来一波,一旦流量的峰值超过了服务的承载能力,服务就挂了,比如有大新闻发生时的某浪微博,比如前些年的12306.
所以,网关必须保证,放过去到达后端服务的流量一定不可以超过服务可以承载的上限。这个上限,是网关和各个服务协商出来的。

限流系统设计

由简到难,限流可以分为单机限流、单集群限流、全集群限流
这里不讨论具体的如漏桶、令牌桶等限流算法,只说概念和思想。

单机限流

单机限流的思想很简单,就是每个机器的限流值 x 机器数量 = 总的限流值。
举个例子,A用户的QPS限制是100,网关部署了10台机器,那么,每台机器限制10QPS就可以了。
先说好处,这种方法实现起来非常简单,每台机器在本地内存计算qps就可以了,超过阈值就拒流。
不过单机限流的缺陷也十分明显,主要体现在两点:
 当网关部署的机器数量发生变化时,每台机器的限流值需要根据机器数调整。现实中,因为扩容、缩容、机器宕机等原因,机器数的变化是常有的事。
 单机限流的前提是,每台网关承载的用户的流量是平均的,但是事实上,在某些时间,用户的流量并不是完全平均分布在每台机器上的。
举个例子:
10台机器,每台限qps10,其中3台每台实际qps是15,因为超限导致用户流量被拒。其余7台每台qps是7。这样用户总的qps = 15 * 3 + 7 * 7 = 94. 用户qps并没有超限,但是却有一部分流量被拒了,这样就很有问题。
实际上,单台限流的阈值也会设置的稍微大一些,以抵消流量不均的问题。
因为上面的问题,单机限流通常作为一种兜底的备用手段,大多数时候用的还是集群限流

集群限流

先来看一个示意图:


相比单机限流,集群限流的计数工作上移到redis集群内进行,解决了单机限流的缺陷。
但是集群限流也不是完美的,因为引入了redis,那么,当网关和redis之间的网络抖动、redis本身故障时,集群限流就失效了,这时候,还是得依靠单机限流进行兜底。
也就是说,集群限流 + 单机限流配合,才是一个比稳妥的方案

真·集群限流

接下来我们来思考这样一个问题:大型网关一般都是多机房、多地域部署的,当然,后端的服务也是多机房、多地域部署的,在保护服务这一点来说,集群限流是够用了。但是对用户来说,还是有一些问题:
比如,用户购买的QPS上限是30,我们的网关部署在中国北、中、南三个地域,那么这30QPS怎么分配呢?
平均肯定不行,用户的流量可能是明显不均衡的,比如用户的业务主要集中在中国北方,那么用户的流量大部分都会进入北方的网关,网关如果限制QPS为10的话,用户肯定来投诉。
那每个地域都限制为30行不行?也不行,如果用户的流量比较均匀的分布在各个地域,那么用户购买了30QPS,实际上可能使用了90QPS,这太亏了。
按照解决单机限流流量不均的思路,搞一个公共的redis集群来计数行不行?
也不行,受限于信号传播速度和天朝的广阔疆域,每个流量都计数,肯定不现实,rt太高会导致限流失去意义,带宽成本也会变得极其昂贵,对redis的规格要求也会很高。总之,很贵还解决不了问题。
有一种巧妙的解决办法是:本地集群阶梯计数 + 全集群检查。
还是刚才的例子:
限流阈值时90,那么三个地域各自计数,当本地域的数值达到30时,去其他两个地域取一次对方当前的计数值,三个地域的计数值加起来,如果超了,告诉另外两个地域超了,开始拒流。如果没超,本地QPS每上涨10,重复一次上述的动作。
这样就能有效的减少与redis的交互次数,同时实现了全地域真·集群限流。
当然,这种全地域集群限流,因为rt和阶梯计数间隔的存在,一定是不准的,但是,比单集群限流还是好很多。

缓解redis的压力

当某个用户流量特别大的时候,redis计数就会遇到典型的热点key问题,导致redis集群单节点压力过大,有两种办法可以解决这个问题:打散和抽样。

打散

打散是指,把热点key加一些后缀,使其变成多个key,从而hash到不通的redis节点上,均摊压力。
比如热点key是abcd,那么打散后,key变成了abcd1、abcd2、abcd3、abcd4。技术时,轮流加1、2、3、4的后缀就可以了。

抽样

抽样是指,针对热点key,不是每个每个请求到来时都进行计数,而是进行一个抽样,比如每10个请求记一次数,这样redis的压力就会降低到十分之一。

说着把流量调度的也说完了哈哈,那下一篇再说说监控好了,顺便推一下我现在在用的国产网关:GOKU,来自Eolinker。我觉得比KONG好用,感兴趣的同学可以自行去了解一下。
www.eolinker.com

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 161,780评论 4 369
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 68,424评论 1 305
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 111,397评论 0 254
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 44,576评论 0 218
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,997评论 3 295
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,945评论 1 224
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 32,107评论 2 317
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,850评论 0 208
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,625评论 1 250
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,804评论 2 253
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,285评论 1 265
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,613评论 3 261
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 33,291评论 3 242
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,164评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,963评论 0 201
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 36,096评论 2 285
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,886评论 2 278

推荐阅读更多精彩内容