分布式系统频次限制实现

起因

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

系统要求

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

流程

1. 设置服务频次限制，如针对某key10QPS
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的访问单人不可超过5QPS，实际上却是5nQPS。所以这个频次限制需要统一存储，统一整个系统的访问频次。

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实现