博客

起因

频次限制（rate limiting）是Web系统比较常见的功能，防止用户频繁访问接口，导致系统负载增加而影响服务的质量。

系统要求

• 针对线上的功能，实现对指定对象有访问频次的限制
• 支持多个客户端访问
• 低延迟
• 承受较大的访问量
• 易于拓展

流程

1. 设置服务频次限制，如针对某
   
key

   10QPS
2. 根据指定
   
key

   ，服务请求
   
ratelimiter

   ，获得是否允许此次访问

伪代码

// 初始换状态
rate := 1 // 设置频率为1ops
needed := 1 // 设置访问1次API需要的令牌数量为1
key := "userA_APIX" // userA访问APIX的场景
tokens := 0 // 当前可用令牌数
lastTime := time.Now() // 上次令牌更新时间

// 时间过去1s
time.Sleep(time.Second)

// userA请求访问APIX
nowTime := time.Now()

// 计算这段时间新生成的令牌数量
newTokens := (nowTime-lastTime)*rate

// 判断是否允许访问
allow := (newTokens+tokens)>needed

// 更新数据
if allow {
    tokens = newTokens+tokens-needed
    lastTime = nowTime

    // 响应用户操作
} else {
    tokens = tokens+newTokens
    lastTime = nowTime

    // 提示用户操作超过限制
}

设计思路

1. 频次限制应该统一存储
   
   
webserver

   是任意可拓展个数的服务，一开始，我将
   
rate limiter

   的存储放在了各自服务中，导致明明我限制的是整个集群这个
   
API

   的访问单人不可超过
   
5

   QPS，实际上却是
   
5n

   QPS。所以这个频次限制需要统一存储，统一整个系统的访问频次。

2. 频次限制本质是一个服务
   
   我试着把存储挪到了
   
redis

   ，并且使用了一些
   
redis

   的命令实现了
   
CAS

   ，
   
redis

   里存了
   
key

   ，
   
tokens

   ，
   
lastTime

   ，实现令牌桶算法，可是算法逻辑仍然放在
   
client

   端（也就是那些web server）。
   
   经过压测，QPS比较低，主要是因为
   
CAS

   的重试率随着并发量上升不断升高，况且访问
   
redis

   增加了网络开销，于是考虑将逻辑如何和数据放到一起。

3. 控制成本
   
   重新开发一个频限服务，需要考虑多节点数据同步，请求转发，failover等功能，我希望以最小的开支实现这个系统。

实现

最终选择了

redis

的

lua

脚本实现了频限功能，既统一了存储，又可以利用

redis cluster

实现了可拓展的频限服务，以最小的成本实现功能。

benchmark

经过测试，MacBook Pro (Retina, 13-inch, Late 2013), CPU 2.4 GHz Intel Core i5, Memory 8 GB 1600 MHz DDR3上能达到

1w+

QPS。

项目地址

ratelimiter的golang实现