分布式系统频次限制实现

最新推荐文章于 2023-11-17 22:05:53 发布

weixin_34319999

最新推荐文章于 2023-11-17 22:05:53 发布

阅读量737

点赞数

CC 4.0 BY-SA版权

文章标签：数据库 java c#

原文链接：http://www.cnblogs.com/pier2/p/6939062.html

起因

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

系统要求

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

流程

设置服务频次限制，如针对某key10QPS
根据指定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

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

设计思路

频次限制应该统一存储
webserver是任意可拓展个数的服务，一开始，我将rate limiter的存储放在了各自服务中，导致明明我限制的是整个集群这个API的访问单人不可超过5QPS，实际上却是5nQPS。所以这个频次限制需要统一存储，统一整个系统的访问频次。
频次限制本质是一个服务
我试着把存储挪到了redis，并且使用了一些redis的命令实现了CAS，redis里存了key，tokens，lastTime，实现令牌桶算法，可是算法逻辑仍然放在client端（也就是那些web server）。
经过压测，QPS比较低，主要是因为CAS的重试率随着并发量上升不断升高，况且访问redis增加了网络开销，于是考虑将逻辑如何和数据放到一起。
控制成本
重新开发一个频限服务，需要考虑多节点数据同步，请求转发，failover等功能，我希望以最小的开支实现这个系统。