大型网站限流算法的实现和改造

最近写了一个限流的插件,所以避免不了的接触到了一些限流算法。本篇文章就来分析一下这几种常见的限流算法

分析之前

  1. 依我个人的理解来说限流的话应该灵活到可以针对每一个接口来做。比如说一个类里面有5个接口,那么我的限流插件就应该能针对每一个接口就行不同的限流方案。所以呢,既然针对的每个接口所以就需要一个可以唯一标示这个接口的key(我取的是类名+方法名+入参)。
  2. 分布式限流强烈推荐使用redis+lua或者nginx+lua来实现。
  3. 这里用2个限流条件来做示例讲一下常见的限流算法:
    1. 接口1它10秒钟最大允许访问100次
    2. 接口2它10秒钟最大允许每个人访问100次。

计数器算法

这个算法可以说是限流算法中最简单的一种算法了。

核心思想

计数器算法的意思呢就是当接口在一个时间单位中被访问时,我就记下来访问次数,直到它访问的次数到达上限。

涉及变量
  1. 接口(key)
  2. 时间单位(expire)
  3. 允许访问多少次(limit)
  4. 访问次数(value)
条件一

当一个请求过来时,我们就会得到这个key。

123456789
if(存在key){   value++;   if(value>=limit){   		不能访问   	}   }else{   	添加key,value为1       设置key过期时间为expire   }
条件二

既然条件一已经实现了,那条件二会复杂么 ?

相比于条件一来说就是同一个key对应了多个用户。那么我们只需要把key加上用户的信息就可以了。比如说 key_用户1、key_用户2。

漏桶算法

核心思想

漏桶算法的意思呢就是一个接口在一个时间单位中允许被访问次数是动态变化的(假如一分钟允许访问60次,那么从开始计时时不管有没有被访问第59秒只允许访问59次,30秒只允许30次)。为什么这样呢,因为有另外一个线程在进行递减操作

涉及变量
  1. 接口(key)
  2. 时间单位(expire)
  3. 允许访问多少次(limit)
  4. 递减间隔时间(interval)
  5. 递减步长(step)
  6. 剩余可访问次数(value)
  7. key的访问时间(lastUpdateTime)
  8. 当前时间(nowTime)(注意nowTime的取值应为应用取得的时间而不是redis或者nginx取得的时间)
条件一

线程一:

12345678
if(存在key){   value--;   if(value<=0){   		不能访问   	}   }else{   	添加key,设置value为limit   }

线程二:

123
while(过去interval时间){   所有key的value-step   }
条件二

参考计数器算法条件二实现。

算法升级

可以看到实现漏桶算法的话需要每隔interval时间都要另外一条线程去遍历所key的value去做递减操作,那么有没有什么办法可以省略这一步呢。答案是肯定有。

12345678910111213
if(存在key){   value--;   if((nowTime-lastUpdateTime)>interval){   	value=value-(nowTime-lastUpdateTime)/interval*step;       lastUpdateTime=nowTime;   }   if(value<=0){   		不能访问   	}   }else{   	添加key,设置value为limit;       lastUpdateTime=nowTime;   }

令牌桶算法

核心思想

令牌桶算法呢,恰恰是和漏桶算法相反的一个算法,不过还是推荐你使用这个。这个算法的原理我不讲,我觉得聪明的你看了伪代码就明白了。

涉及变量
  1. 接口(key)
  2. 时间单位(expire)
  3. 允许访问多少次(limit)
  4. 递增间隔时间(interval)
  5. 递增步长(step)
  6. 当前可访问次数(value)
  7. key的访问时间(lastUpdateTime)
  8. 当前时间(nowTime)(参照漏桶算法需要注意的点)
条件一

线程一:

12345678
if(存在key){   value++;   if(value>=limit){   		不能访问   	}   }else{   	添加key,设置value为limit   }

线程二:

123
while(过去interval时间){   所有key的value+step   }
条件二

参考计算器算法条件二实现。

算法升级

参考漏桶算法升级实现。

代码

代码实现请参考我的限流框架https://github.com/2388386839/syj-ratelimit

原文地址:https://www.cnblogs.com/zhixiang-org-cn/p/9710814.html

时间: 2024-10-13 21:15:52

大型网站限流算法的实现和改造的相关文章

网站限流处理

1.常见两种方式 漏桶算法和令牌桶算法 漏桶算法:1.有一个固定容量的漏桶,已固定的速率流出水滴. 2.可以任意速率流入水滴到漏桶 3.当漏桶满了,水溢出(相当于丢弃) 令牌桶算法: 1.以固定的速率向桶里放令牌 2.当桶内的令牌数量达到最大值后,后续放入的令牌被丢弃 3.当需要发送N个单位大小的数据时,就从桶内去N个令牌 4.当桶内的令牌数量小于设定的大小时,不能删除令牌,也就是不能发送数据,这是数据可能被丢弃,也可能被缓冲区缓存下来. 2.其它方式 统计计数,主要思想是记录指定时间内的访问量

接口限流

一.什么是限流 使资源以限定的速率被使用.比如:地铁限流,高峰时段限制单位时间内的客流量:电路中的限流器,可以保证电路不超过额定的电流:网站限流,抢购,瞬间的高峰对于后台来说肯定是需要一个限流处理为可接受的速率进行处理. 二.为什么要限流 比如:地铁不限流量,挤爆了:电路不限流,灯爆了:网站不限流,撑爆了. 三.限流的几种方式 常用的限流算法有两种:漏桶算法和令牌桶算法. 漏桶算法:桶中水以限定的速度流出来.缺点:水满溢出.突发请求不能尽快处理,被调整为固定速率. 令牌桶算法:系统会以一个限定的

大型网站首页执行时间0.3秒,性能算好还是算坏?

正在编写一个大型网站,本机调试时首页执行时间到了0.3秒(APP_DEBUG为true时),这样的性能算好还是算坏?网站日pv20万左右,日IP2万左右. 本机配置:CPU:AMD A8-7650k,内存:8g 极好 : 20毫秒内 保证 : 80毫秒内 可以接受 100毫秒 再大有些难以接受 开启缓存 可以改善很多

微服务之间的通讯安全(四)-JWT优化之日志、错误处理、限流及JWT改造后执行流程梳理

前面我们已经完成了通过JWT的认证和授权的改造,可以看到我们的代码中没有认证和授权的过滤器(Filter)了,基本上由SpringSecurity的过滤器来接管了,接下来我们来看一下怎么在SpringSecurity的过滤器链上加上我们自己的逻辑,比如日志和限流. 1.在SpringSecurity过滤器链上添加审计过滤器 1.1.创建日志过滤器,因为我们根据我们之前审计机制的位置,要把日志过滤器放到认证之后,授权之前.认证的过滤器会把JWT令牌转化为Authentication,然后放到安全上

网站防刷限流

我在nginx 和tengine 之间选择了tengine.tengine是淘宝公司在nginx 研发的.同时也测试过nginx 在一些功能方面不是很好.比如: 限流这块,nginx目前只支持对ip限流 还有对后端服务器的检测方面都不如tengine Tengine version: Tengine/2.3.1nginx version: nginx/1.16.0 今天要说的模块: limit_req_zone 可以 支持对iIP 地址 基于URL,和URL的参数组合限流 在全局配置定义 lim

大型网站的 HTTPS 实践(1):HTTPS 协议和原理

转自:http://op.baidu.com/2015/04/https-s01a01/ 1 前言 百度已经于近日上线了全站 HTTPS 的安全搜索,默认会将 HTTP 请求跳转成 HTTPS.本文重点介绍 HTTPS 协议, 并简单介绍部署全站 HTTPS 的意义. 2 HTTPS 协议概述 HTTPS 可以认为是 HTTP + TLS.HTTP 协议大家耳熟能详了,目前大部分 WEB 应用和网站都是使用 HTTP 协议传输的. TLS 是传输层加密协议,它的前身是 SSL 协议,最早由 ne

关于大型网站技术演进的思考--存储的瓶颈(转)

(一)第一部分 前不久公司请来了位互联网界的技术大牛跟我们做了一次大型网站架构的培训,两天12个小时信息量非常大,知识的广度和难度也非常大,培训完后我很难完整理出全部听到的知识,今天我换了个思路是回味这次培训,这个思路就是通过本人目前的经验和技术水平来思考下大型网站技术演进的过程. 首先我们要思考一个问题,什么样的网站才是大型网站,从网站的技术指标角度考虑这个问题人们很容易犯一个毛病就是认为网站的访问量是衡量的指标,懂点行的人也许会认为是网站在单位时间里的并发量的大小来作为指标,如果按这些标准那

大型网站的 HTTPS 实践(一)—— HTTPS 协议和原理(转)

原文链接:http://op.baidu.com/2015/04/https-s01a01/ 1 前言 百度已经于近日上线了全站 HTTPS 的安全搜索,默认会将 HTTP 请求跳转成 HTTPS.本文重点介绍 HTTPS 协议, 并简单介绍部署全站 HTTPS 的意义. 2 HTTPS 协议概述 HTTPS 可以认为是 HTTP + TLS(Transport Layer Security).HTTP 协议大家耳熟能详了,目前大部分 WEB 应用和网站都是使用 HTTP 协议传输的. TLS

大型网站架构改进历程-转 (刚进博客园就看到这么一篇好文章感触颇深)

存储的瓶颈(1) 前不久公司请来了位互联网界的技术大牛跟我们做了一次大型网站架构的培训,两天12个小时信息量非常大,知识的广度和难度也非常大,培训完后我很难 完整理出全部听到的知识,今天我换了个思路是回味这次培训,这个思路就是通过本人目前的经验和技术水平来思考下大型网站技术演进的过程. 大型网站定义 首先我们要思考一个问题,什么样的网站才是大型网站,从网站的技术指标角度考虑这个问题人们很容易犯一个毛病就是认为网站的访问量是衡量的指标,懂点 行的人也许会认为是网站在单位时间里的并发量的大小来作为指