对rate limiting功能的思考

频率限制,应该是针对调用方的限制,同时也对被调用对象的保护。

例如每个IP对`/gateway/ticket/ticket2ctx`接口每秒钟调用次数不超过200次。

故频率定义为: 调用方属性组合 X 被调用对象属性组合 x 次数 x 间隔

调用方属性包括: IP,应用ID等

被调用对象属性:一般是接口

间隔:1秒、1分钟、1小时、1每天

可以在两个地方进行频率限制:
一个是在网关,使用“调用方IP X 接口”
一个是在开放平台,使用“调用方AppId x 接口” | 调用方appId x 接口

不同间隔的限制可以同时使用,如 rate <= 100rp/sec 且 rate <= 3500 rp/min 在逻辑正确及性能方面较符合的算法包括:吊桶算法、循环队列算法、令牌通算法、漏桶算法。

吊桶算法

image2018-2-28 18_45_59
这种算法没有办法保证任意1秒(不是整数开始)都限制n个请求。本质是计数器方式,粗暴,非精确。

循环队列算法

image2018-2-28 18_48_46

维护最近n个请求的时间,当有新请求时,查看一下n个之前的请求的时间,如果大于1秒就放过,小于1秒就拒绝。
缺点,n很大时,空间消耗大。

token bucket算法

image2018-2-28 18_51_9

令牌桶会以一定速率产生令牌放入桶中,满了以后会丢弃或暂停产生,数据通过时需要持有一个令牌,没有令牌说明超过了速率限制。令牌桶算法允许突发流量,如突然将桶内令牌都消耗完成

漏桶算法

image2018-2-28 18_51_58
漏桶算法中,水以一定速率放到漏桶里,然后漏桶以一定的速率向外流水。所以最大的速率就是出水的速率。不能出现突发流量。

限流可以分为:
1.应用级限流,只是单应用实例内的请求限流
2.分布式限流。

网关部署到多台机器,为了保证正确的限流,需要全局限流,即分布式限流。

限流vs熔断:
限流一般在被调用侧实施,而熔断则在调用侧做。

资料:

http://jinnianshilongnian.iteye.com/blog/2305117

This entry was posted in 微服务