Redis 限流系统的设计策略！这篇文章终于讲明白了

ゞ浴缸里的玫瑰 2022-10-16 04:59 4阅读 0赞

![96c09f0f55a46dad82ca2d4b5b0827b8.png][]![336e28f331028258b6a9eb700c838c6d.gif][]

回复【**面试题**】获取2021年最新java面试题合集～

![fd3319557f35203d4f2b10221ff632e9.png][]

本文讲述**基于 Redis 的限流系统的设计**，主要会谈及限流系统中**限流策略**这个功能的设计；在实现方面，算法使用的是**令牌桶**算法来，访问 Redis 使用 lua 脚本。

##  ##

1、概念

In computer networks, **rate limiting** is used to control the rate of traffic sent or received by a network interface controller and is used to prevent DoS attacks

用我的理解翻译一下：限流是对系统的**出入流量**进行**控制**，防止大流量出入，导致**资源**不足，系统不稳定。

限流系统是对资源访问的控制组件，控制主要的两个功能：**限流策略**和**熔断策略**，对于熔断策略，不同的系统有不同的熔断策略诉求，有的系统希望直接拒绝、有的系统希望排队等待、有的系统希望服务降级、有的系统会定制自己的熔断策略，很难一一列举，所以本文只针对**限流策略**这个功能做详细的设计。

针对**限流策略**这个功能，限流系统中有两个基础概念：资源和策略。

*  **资源** ：或者叫稀缺资源，被流量控制的对象；比如写接口、外部商户接口、大流量下的读接口
 *  **策略** ：限流策略由限流算法和可调节的参数两部分组成

> 熔断策略：**超出速率阈值的请求**的**处理策略**，是我自己理解的一个叫法，不是业界主流的说法。

##  ##

2、限流算法

*  限制瞬时并发数
 *  限制时间窗最大请求数
 *  令牌桶

###  ###

2.1、限制瞬时并发数

###     ###

**定义**：瞬时**并发数**，系统同时处理的请求 / 事务数量

**优点**：这个算法能够实现控制并发数的效果

**缺点**：使用场景比较单一，一般用来对入流量进行控制

**java 伪代码实现**：

AtomicInteger atomic = new AtomicInteger(1)
    try {    
        if(atomic.incrementAndGet() > 限流数) {  
            //熔断逻辑    } else {
            //处理逻辑
        }
    } finally {    atomic.decrementAndGet();}

###  ###

2.2、限制时间窗最大请求数

###     ###

**定义**：时间窗最大请求数，指定的时间范围内允许的最大请求数

**优点**：这个算法能够满足绝大多数的流控需求，通过时间窗最大请求数可以直接换算出最大的 QPS（QPS = 请求数 / 时间窗）

**缺点**：这种方式可能会出现流量不平滑的情况，时间窗内一小段流量占比特别大

**lua 代码实现**：

--- 资源唯一标识
    local key = KEYS[1]
    --- 时间窗最大并发数
    local max_window_concurrency = tonumber(ARGV[1])  
    --- 时间窗
    local window = tonumber(ARGV[2])  
    --- 时间窗内当前并发数
    local curr_window_concurrency = tonumber(redis.call('get', key) or 0)  
    if current + 1 > limit then
        return false
    else
        redis.call("INCRBY", key,1)    
        if window > -1 then
            redis.call("expire", key,window)    
        end
        return true
    end

###  ###

2.3、令牌桶

###     ###

![4dd72d6b4becce8d318d7adfc9d1fa63.png][]

**算法描述**

*  假如用户配置的平均发送速率为 r，则每隔 1/r 秒一个令牌被加入到桶中
 *  假设桶中最多可以存放 b 个令牌。如果令牌到达时令牌桶已经满了，那么这个令牌会被丢弃
 *  当流量以速率 v 进入，从桶中以速率 v 取令牌，拿到令牌的流量通过，拿不到令牌流量不通过，执行熔断逻辑

**属性**

*  长期来看，符合流量的速率是受到令牌添加速率的影响，被稳定为：r
 *  因为令牌桶有一定的存储量，可以抵挡一定的流量突发情况
 *   *  M 是以字节 / 秒为单位的最大可能传输速率：M>r
     *  T max = b/(M-r)    承受最大传输速率的时间
     *  B max = T max \* M   承受最大传输速率的时间内传输的流量

**优点**：流量比较平滑，并且可以抵挡一定的流量突发情况

因为我们限流系统的实现就是基于令牌桶这个算法，具体的代码实现参考下文。

##  ##

3、工程实现

###  ###

3.1、技术选型

###     ###

*  mysql: 存储限流策略的参数等元数据
 *  redis+lua: 令牌桶算法实现

> 说明：因为我们把 redis 定位为：缓存、计算媒介，所以元数据都是存在 db 中

###  ###

3.2、架构图

![8d289d354efd3583622bfb98ce4382ff.png][]

###  ###

3.3、 数据结构

###     ###

<table> 
 <thead> 
  <tr> 
   <th>字段</th> 
   <th>描述</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>name</td> 
   <td>令牌桶的唯一标示</td> 
  </tr> 
  <tr> 
   <td>apps</td> 
   <td>能够使用令牌桶的应用列表</td> 
  </tr> 
  <tr> 
   <td>max_permits</td> 
   <td>令牌桶的最大令牌数</td> 
  </tr> 
  <tr> 
   <td>rate</td> 
   <td>向令牌桶中添加令牌的速率</td> 
  </tr> 
  <tr> 
   <td>created_by</td> 
   <td>创建人</td> 
  </tr> 
  <tr> 
   <td>updated_by</td> 
   <td>更新人</td> 
  </tr> 
 </tbody> 
</table>

限流系统的实现是基于 redis 的，本可以和应用无关，但是为了做限流元数据配置的统一管理，按应用维度管理和使用，在数据结构中加入了** apps** 这个字段，出现问题，排查起来也比较方便。

###  ###

3.4、代码实现

#### **3.4.1、代码实现遇到的问题** ####

参考令牌桶的算法描述，一般思路是在 RateLimiter-client 放一个重复执行的线程，线程根据配置往令牌桶里添加令牌，这样的实现由如下缺点：

*  需要为每个令牌桶配置添加一个重复执行的线程
 *  重复的间隔精度不够精确：线程需要每 1/r 秒向桶里添加一个令牌，当 r>1000 时间线程执行的时间间隔根本没办法设置（从后面性能测试的变现来看 RateLimiter-client 是可以承担 QPS > 5000 的请求速率）

####     ####

#### **3.4.2、解决方案** ####

基于上面的缺点，参考了 google 的 guava 中 RateLimiter 中的实现，我们使用了触发式添加令牌的方式。

![76553aeeb094f1ca321054f5f330b24e.png][]

**算法描述**

*  基于上述的令牌桶算法
 *  将添加令牌改成触发式的方式，取令牌的是做添加令牌的动作
 *  在去令牌的时候，通过计算上一次添加令牌和当前的时间差，计算出这段间应该添加的令牌数，然后往桶里添加
 *   *  curr\_mill\_second = 当前毫秒数
     *  last\_mill\_second = 上一次添加令牌的毫秒数
     *  r = 添加令牌的速率
     *  reserve\_permits = (curr\_mill\_second-last\_mill\_second)/1000 \* r
 *  添加完令牌之后再执行取令牌逻辑

####     ####

#### **3.4.3、 lua 代码实现** ####

--- 获取令牌
    --- 返回码
    --- 0 没有令牌桶配置
    --- -1 表示取令牌失败，也就是桶里没有令牌
    --- 1 表示取令牌成功
    --- @param key 令牌（资源）的唯一标识
    --- @param permits  请求令牌数量
    --- @param curr_mill_second 当前毫秒数
    --- @param context 使用令牌的应用标识
    local function acquire(key, permits, curr_mill_second, context)
        local rate_limit_info = redis.pcall("HMGET", key, "last_mill_second", "curr_permits", "max_permits", "rate", "apps")    
        local last_mill_second = rate_limit_info[1]    
        local curr_permits = tonumber(rate_limit_info[2])    
        local max_permits = tonumber(rate_limit_info[3])    
        local rate = rate_limit_info[4]    
        local apps = rate_limit_info[5]    
        --- 标识没有配置令牌桶
        if type(apps) == 'boolean' or apps == nil or not contains(apps, context) then
            return 0
        end
        local local_curr_permits = max_permits;    
        --- 令牌桶刚刚创建，上一次获取令牌的毫秒数为空
        --- 根据和上一次向桶里添加令牌的时间和当前时间差，触发式往桶里添加令牌
        --- 并且更新上一次向桶里添加令牌的时间
        --- 如果向桶里添加的令牌数不足一个，则不更新上一次向桶里添加令牌的时间
        if (type(last_mill_second) ~= 'boolean' and last_mill_second ~= false and last_mill_second ~= nil) then
            local reverse_permits = math.floor(((curr_mill_second - last_mill_second) / 1000) * rate)        
            local expect_curr_permits = reverse_permits + curr_permits;
            local_curr_permits = math.min(expect_curr_permits, max_permits);      
             --- 大于0表示不是第一次获取令牌，也没有向桶里添加令牌
            if (reverse_permits > 0) then
                redis.pcall("HSET", key, "last_mill_second", curr_mill_second)      
          end
        else
            redis.pcall("HSET", key, "last_mill_second", curr_mill_second)  
        end
        local result = -1
        if (local_curr_permits - permits >= 0) then
            result = 1
            redis.pcall("HSET", key, "curr_permits", local_curr_permits - permits)    
        else
            redis.pcall("HSET", key, "curr_permits", local_curr_permits)    
        end
        return result
    end

关于限流系统的所有实现细节，我都已经放到 github 上，gitbub 地址：https://github.com/wukq/rate-limiter，有兴趣的同学可以前往查看，由于笔者经验与知识有限，代码中如有错误或偏颇，欢迎探讨和指正。

###     ###

### **3.4.4、管理界面** ###

前面的设计中，限流的配置是和应用关联的，为了更够更好的管理配置，需要一个统一的管理页面去对配置进行管控：

*  按应用对限流配置进行管理
 *  不同的人分配不同的权限；相关人员有查看配置的权限，负责人有修改和删除配置的权限

![a5a3bfa69884c437a2e6e646049a24a6.png][]

###     ###

### **3.5、性能测试** ###

**配置**：aws-elasticcache-redis 2 核 4g

因为 Ratelimiter-client 的功能比较简单，基本上是 redis 的性能打个折扣。

*  单线程取令牌：Ratelimiter-client 的 QPS = 250/s
 *  10 个线程取令牌：Ratelimiter-client 的 QPS = 2000/s
 *  100 个线程取令牌：Ratelimiter-client 的 QPS = 5000/s

##  ##

4、总结

限流系统从设计到实现都比较简单，但是确实很实用，用四个字来形容就是：**短小强悍**，其中比较重要的是结合公司的权限体系和系统结构，设计出符合自己公司规范的限流系统。

**不足**：

*  redis 我们用的是单点 redis，只做了主从，没有使用 redis 高可用集群（可能使用 redis 高可用集群，会带来新的问题）
 *  限流系统目前只做了应用层面的实现，没有做接口网关上的实现
 *  熔断策略需要自己定制，如果实现的好一点，可以给一些常用的熔断策略模板

往期推荐

[【超多代码细节】Redis实现点赞、取消点赞的？][Redis]

[老板说java后台管理系统3天内必须上线，我丢了这套源码给他][java_3]

[Redis排行榜功能实现？多排序条件][Redis 1]

[Redis实现微信“附近的人”功能？，这篇文章作用太大了][Redis 2]

[妹子不会Elasticsearch，硬核大佬为博芳心手绘图解教程][Elasticsearch]

[Linux主机性能监控工具Netdata][Linux_Netdata]

[如何进行软件架构设计？本质是：业务逻辑和技术分离][Link 1]

[RabbitMQ几种工作模式，实现延时消息的两种案例][RabbitMQ]

参考书籍：

1.《Redis 设计与实现》

2.《Lua 编程指南》

参考文章：

1. redis 官网

2. lua 编码规范

3. 聊聊高并发系统之限流特技

4. guava Ratelimiter 实现

5. Token\_bucket wiki 词条

**--完--**

**![85e36452966a07967c33c950f10ed4ee.gif][]**

**回复**【**干货**】获取精选干货视频教程

**回复**【**加群**】加入疑难问题攻坚交流群

**回复**【**mat**】获取内存溢出问题分析详细文档教程

**回复**【**赚钱**】获取用java写一个能赚钱的微信机器人

**回复**【**副业**】获取程序员副业攻略一份

![0a982dc059d6053f8e8bdd955845475c.png][]

![e69a7b5965d1c3a8e97893e037e63b27.gif][]

码字不易，点个再看吧

[96c09f0f55a46dad82ca2d4b5b0827b8.png]: https://img-blog.csdnimg.cn/img_convert/96c09f0f55a46dad82ca2d4b5b0827b8.png
[336e28f331028258b6a9eb700c838c6d.gif]: /images/20221014/40cfc9e19ef04f56a2d575f68fb83090.png
[fd3319557f35203d4f2b10221ff632e9.png]: /images/20221014/6b3a450b503c466ebdcd52aee82d6ac9.png
[4dd72d6b4becce8d318d7adfc9d1fa63.png]: /images/20221014/cfb913f538cc44429937cbc4904c56cd.png
[8d289d354efd3583622bfb98ce4382ff.png]: /images/20221014/c9e00559e7cb4bc89d584be0f5a24132.png
[76553aeeb094f1ca321054f5f330b24e.png]: /images/20221014/d9f36e25d808492fb303d74ff4903310.png
[a5a3bfa69884c437a2e6e646049a24a6.png]: /images/20221014/718bfa57329b474db73c2842c85293f1.png
[Redis]: http://mp.weixin.qq.com/s?__biz=MzU2NDc4MjE2Ng%3D%3D&chksm=fc44e0cacb3369dc03946727b2403197bdbf309722af8402e605fcfa603abfa603bb1601c83a&idx=1&mid=2247489011&scene=21&sn=c367f48493d6e7ac5044ea67df6db7f3#wechat_redirect
[java_3]: http://mp.weixin.qq.com/s?__biz=MzU2NDc4MjE2Ng%3D%3D&chksm=fc44e0cacb3369dc4c110183d880d54988ffb7e8082fb2a59974540dee98f74fdd74afb81bf1&idx=2&mid=2247489011&scene=21&sn=a009b2aa8ea806eec720f32dd5de3aff#wechat_redirect
[Redis 1]: http://mp.weixin.qq.com/s?__biz=MzU2NDc4MjE2Ng%3D%3D&chksm=fc44e1dbcb3368cdf5c740b0e0ba98361e745d3ffb69df6d98c6ab76189b00ecd65f21287972&idx=1&mid=2247488738&scene=21&sn=d9f9d1a8e4abea5140790077690c1dde#wechat_redirect
[Redis 2]: http://mp.weixin.qq.com/s?__biz=MzU2NDc4MjE2Ng%3D%3D&chksm=fc44e18dcb33689bc77bbff163f2b7e7fec39aa756d7f6cd3cdd90397571c18d3fcc544fa165&idx=1&mid=2247488692&scene=21&sn=0b1b3ab3d5ccedcd63fd641fce93b357#wechat_redirect
[Elasticsearch]: http://mp.weixin.qq.com/s?__biz=MzU2NDc4MjE2Ng%3D%3D&chksm=fc44e199cb33688f32a66ad683b4b6ca4b7abcb7196f2b0e6de3936b106c9d980596f5f733e2&idx=1&mid=2247488672&scene=21&sn=3953b7a657da693c2a4074b0eb2d249d#wechat_redirect
[Linux_Netdata]: http://mp.weixin.qq.com/s?__biz=MzU2NDc4MjE2Ng%3D%3D&chksm=fc44e199cb33688f253b08a556b0d255bc7a00809482707eb2e149b866cd898ad233509fd2cc&idx=3&mid=2247488672&scene=21&sn=3bc9a804854a60cda501d160a62089ed#wechat_redirect
[Link 1]: http://mp.weixin.qq.com/s?__biz=MzU2NDc4MjE2Ng%3D%3D&chksm=fc44e102cb33681463f642189e32f84c161b116636f29fa0585bf14df5b9735080076734ff72&idx=1&mid=2247488571&scene=21&sn=3695fb5f3c6730326864a109da1b960a#wechat_redirect
[RabbitMQ]: http://mp.weixin.qq.com/s?__biz=MzU2NDc4MjE2Ng%3D%3D&chksm=fc44e102cb33681436ddbd60149799c0b472075dbba53218f699dfb60647c468a4c48df8aa5b&idx=2&mid=2247488571&scene=21&sn=b4ebd9762e52f73dea21e827cc66c8b0#wechat_redirect
[85e36452966a07967c33c950f10ed4ee.gif]: /images/20221014/831ef92815144de29f3f3ea574b7af79.png
[0a982dc059d6053f8e8bdd955845475c.png]: /images/20221014/c0f1b1568329438dbebcf3e897e4dcf1.png
[e69a7b5965d1c3a8e97893e037e63b27.gif]: /images/20221014/5fc9e5d2e31641dab3ff67faf34bdc52.png