我司“双11”限流方案,进来抄作业!
欢迎关注方志朋的博客,回复”666“获面试宝典
日常生活中,有哪些需要限流的地方?像我旁边有一个国家景区,平时可能根本没什么人前往,但是一到十一或者春节就人满为患,这时候景区管理人员就会实行一系列的政策来限制进入人流量,为什么要限流呢?
假如景区能容纳一万人,现在进去了三万人,势必摩肩接踵,整不好还会有事故发生,这样的结果就是所有人的体验都不好。
如果发生了事故景区可能还要关闭,导致对外不可用,这样的后果就是所有人都觉得体验糟糕透了。
限流的思想就是,在保证可用的情况下尽可能多增加进入的人数,其余的人在外面排队等待,保证里面的一万人可以正常游玩。
回到网络上,同样也是这个道理,例如某某明星公布了恋情,访问从平时的 50 万增加到了 500 万,系统最多可以支撑 200 万访问、双十一的秒杀活动、12306 的抢票等。
那么就要执行限流规则,保证是一个可用的状态,不至于服务器崩溃导致所有请求不可用。
限流思路
对系统服务进行限流,一般有如下几个模式:
①熔断
系统在设计之初就把熔断措施考虑进去。当系统出现问题时,如果短时间内无法修复,系统要自动做出判断,开启熔断开关,拒绝流量访问,避免大流量对后端的过载请求。
系统也应该能够动态监测后端程序的修复情况,当程序已恢复稳定时,可以关闭熔断开关,恢复正常服务。
常见的熔断组件有 Hystrix 以及阿里的 Sentinel,两种互有优缺点,可以根据业务的实际情况进行选择。
②服务降级
将系统的所有功能服务进行一个分级,当系统出现问题需要紧急限流时,可将不是那么重要的功能进行降级处理,停止服务,这样可以释放出更多的资源供给核心功能的去用。
例如在电商平台中,如果突发流量激增,可临时将商品评论、积分等非核心功能进行降级,停止这些服务,释放出机器和 CPU 等资源来保障用户正常下单。
而这些降级的功能服务可以等整个系统恢复正常后,再来启动,进行补单/补偿处理。
除了功能降级以外,还可以采用不直接操作数据库,而全部读缓存、写缓存的方式作为临时降级方案。
③延迟处理
这个模式需要在系统的前端设置一个流量缓冲池,将所有的请求全部缓冲进这个池子,不立即处理。
然后后端真正的业务处理程序从这个池子中取出请求依次处理,常见的可以用队列模式来实现。
这就相当于用异步的方式去减少了后端的处理压力,但是当流量较大时,后端的处理能力有限,缓冲池里的请求可能处理不及时,会有一定程度延迟。后面具体的漏桶算法以及令牌桶算法就是这个思路。
④特权处理
这个模式需要将用户进行分类,通过预设的分类,让系统优先处理需要高保障的用户群体,其它用户群的请求就会延迟处理或者直接不处理。
缓存、降级、限流区别如下:
缓存,是用来增加系统吞吐量,提升访问速度提供高并发。
降级,是在系统某些服务组件不可用的时候、流量暴增、资源耗尽等情况下,暂时屏蔽掉出问题的服务,继续提供降级服务,给用户尽可能的友好提示,返回兜底数据,不会影响整体业务流程,待问题解决再重新上线服务
限流,是指在使用缓存和降级无效的场景。比如当达到阈值后限制接口调用频率,访问次数,库存个数等,在出现服务不可用之前,提前把服务降级。只服务好一部分用户。
限流的算法
限流算法很多,常见的有三类,分别是计数器算法、漏桶算法、令牌桶算法,下面逐一讲解。
①计数器算法
简单粗暴,比如指定线程池大小,指定数据库连接池大小、Nnginx 连接数等,这都属于计数器算法。
计数器算法是限流算法里最简单也是最容易实现的一种算法。举个例子,比如我们规定对于 A 接口,我们 1 分钟的访问次数不能超过 100 个。
那么我们可以这么做:在一开始的时候,我们可以设置一个计数器 counter,每当一个请求过来的时候,counter 就加 1。
如果 counter 的值大于 100 并且该请求与第一个请求的间隔时间还在 1 分钟之内,那么说明请求数过多,拒绝访问。
如果该请求与第一个请求的间隔时间大于 1 分钟,且 counter 的值还在限流范围内,那么就重置 counter,就是这么简单粗暴。
②漏桶算法
漏桶算法思路很简单,水(请求)先进入到漏桶里,漏桶以一定的速度出水,当水流入速度过大会超过桶可接纳的容量时直接溢出,可以看出漏桶算法能强行限制数据的传输速率。
削峰:有大量流量进入时,会发生溢出,从而限流保护服务可用。
缓冲:不至于直接请求到服务器,缓冲压力,消费速度固定,因为计算性能固定。
③令牌桶算法
令牌桶与漏桶相似,不同的是令牌桶桶中放了一些令牌,服务请求到达后,要获取令牌之后才会得到服务。
举个例子,我们平时去食堂吃饭,都是在食堂内窗口前排队的,这就好比是漏桶算法,大量的人员聚集在食堂内窗口外,以一定的速度享受服务。
如果涌进来的人太多,食堂装不下了,可能就有一部分人站到食堂外了,这就没有享受到食堂的服务,称之为溢出,溢出可以继续请求,也就是继续排队,那么这样有什么问题呢?
如果这时候有特殊情况,比如有些赶时间的志愿者啦或者高三要高考啦,这种情况就是突发情况。
如果也用漏桶算法那也得慢慢排队,这也就没有解决我们的需求,对于很多应用场景来说,除了要求能够限制数据的平均传输速率外,还要求允许某种程度的突发传输。
这时候漏桶算法可能就不合适了,令牌桶算法更为适合。
如图所示,令牌桶算法的原理是系统会以一个恒定的速度往桶里放入令牌,而如果请求需要被处理,则需要先从桶里获取一个令牌,当桶里没有令牌可取时,则拒绝服务。
并发限流
简单来说就是设置系统阈值总的 QPS 个数,这些也挺常见的,就拿 Tomcat 来说,很多参数就是出于这个考虑。
例如配置的 acceptCount 设置响应连接数,maxConnections 设置瞬时最大连接数,maxThreads 设置最大线程数。
在各个框架或者组件中,并发限流体现在下面几个方面:
限制总并发数(如数据库连接池、线程池)
限制瞬时并发数(nginx 的 limit_conn 模块,用来限制瞬时并发连接数)
限制时间窗口内的平均速率(如 Guava 的 RateLimiter、nginx 的 limit_req 模块,限制每秒的平均速率)
其他的还有限制远程接口调用速率、限制 MQ 的消费速率。
另外还可以根据网络连接数、网络流量、CPU 或内存负载等来限流。
有了并发限流,就意味着在处理高并发的时候多了一种保护机制,不用担心瞬间流量导致系统挂掉或雪崩,最终做到有损服务而不是不服务。
但是限流需要评估好,不能乱用,否则一些正常流量出现一些奇怪的问题而导致用户体验很差造成用户流失。
接口限流
接口限流分为两个部分,一是限制一段时间内接口调用次数,参照前面限流算法的计数器算法,二是设置滑动时间窗口算法。
①接口总数
控制一段时间内接口被调用的总数量,可以参考前面的计数器算法,不再赘述。
②接口时间窗口
固定时间窗口算法(也就是前面提到的计数器算法)的问题是统计区间太大,限流不够精确,而且在第二个统计区间时没有考虑与前一个统计区间的关系与影响(第一个区间后半段+第二个区间前半段也是一分钟)。
为了解决上面我们提到的临界问题,我们试图把每个统计区间分为更小的统计区间,更精确的统计计数。
在上面的例子中,假设 QPS 可以接受 100 次查询/秒,前一分钟前 40 秒访问很低,后 20 秒突增,并且这个持续了一段时间,直到第二分钟的第 40 秒才开始降下来。
根据前面的计数方法,前一秒的 QPS 为 94,,后一秒的 QPS 为 92,那么没有超过设定参数。
但是在中间区域,QPS 达到了 142,,这明显超过了我们的允许的服务请求数目,所以固定窗口计数器不太可靠,需要滑动窗口计数器。
计数器算法其实就是固定窗口算法,只是它没有对时间窗口做进一步地划分,所以只有 1 格。
由此可见,当滑动窗口的格子划分的越多,也就是将秒精确到毫秒或者纳秒,那么滑动窗口的滚动就越平滑,限流的统计就会越精确。需要注意的是,消耗的空间就越多。
限流实现
这一部分是限流的具体实现,简单说说,毕竟长篇代码没人愿意看。
①guava 实现
引入包:
<!-- https://mvnrepository.com/artifact/com.google.guava/guava -->
<dependency><groupId>com.google.guava</groupId><artifactId>guava</artifactId><version>28.1-jre</version>
</dependency>
核心代码:
LoadingCache<Long, AtomicLong> counter = CacheBuilder.newBuilder().expireAfterWrite(2, TimeUnit.SECONDS).build(new CacheLoader<Long, AtomicLong>() {@Overridepublic AtomicLong load(Long secend) throws Exception {// TODO Auto-generated method stubreturn new AtomicLong(0);}});
counter.get(1l).incrementAndGet();
②令牌桶实现
稳定模式(SmoothBursty:令牌生成速度恒定):
public static void main(String[] args) {// RateLimiter.create(2)每秒产生的令牌数RateLimiter limiter = RateLimiter.create(2);// limiter.acquire() 阻塞的方式获取令牌System.out.println(limiter.acquire());;try {Thread.sleep(2000);} catch (InterruptedException e) {// TODO Auto-generated catch blocke.printStackTrace();}System.out.println(limiter.acquire());;System.out.println(limiter.acquire());;System.out.println(limiter.acquire());;System.out.println(limiter.acquire());;System.out.println(limiter.acquire());;System.out.println(limiter.acquire());;
}
RateLimiter.create(2) 容量和突发量,令牌桶算法允许将一段时间内没有消费的令牌暂存到令牌桶中,用来突发消费。
渐进模式(SmoothWarmingUp:令牌生成速度缓慢提升直到维持在一个稳定值):
// 平滑限流,从冷启动速率(满的)到平均消费速率的时间间隔
RateLimiter limiter = RateLimiter.create(2,1000l,TimeUnit.MILLISECONDS);
System.out.println(limiter.acquire());;
try {Thread.sleep(2000);
} catch (InterruptedException e) {// TODO Auto-generated catch blocke.printStackTrace();
}
System.out.println(limiter.acquire());
System.out.println(limiter.acquire());
System.out.println(limiter.acquire());
System.out.println(limiter.acquire());System.out.println(limiter.acquire());
System.out.println(limiter.acquire());
超时:
boolean tryAcquire = limiter.tryAcquire(Duration.ofMillis(11));
在 timeout 时间内是否能够获得令牌,异步执行。
③分布式系统限流(Nginx+Lua 实现)
可以使用 resty.lock 保持原子特性,请求之间不会产生锁的重入:
https://github.com/openresty/lua-resty-lock
使用 lua_shared_dict 存储数据:
local locks = require "resty.lock"local function acquire()local lock =locks:new("locks")local elapsed, err =lock:lock("limit_key") -- 互斥锁 保证原子特性local limit_counter =ngx.shared.limit_counter -- 计数器local key = "ip:" ..os.time()local limit = 5 -- 限流大小local current =limit_counter:get(key)if current ~= nil and current + 1> limit then -- 如果超出限流大小lock:unlock()return 0endif current == nil thenlimit_counter:set(key, 1, 1) -- 第一次需要设置过期时间,设置key的值为1,-- 过期时间为1秒elselimit_counter:incr(key, 1) -- 第二次开始加1即可endlock:unlock()return 1
end
ngx.print(acquire())
作者:等不到的口琴
编辑:陶家龙
出处:https://urlify.cn/fuAB7j
热门内容:
还在付费使用XShell?我选择这款国产良心工具,完全免费!
八股文!让我收获了诸多offer~
杭州程序员从互联网跳央企,晒一天工作和收入,网友:待一年就废
别人家的公司的 1024 程序员节 ! 羡慕了!
最近面试BAT,整理一份面试资料《Java面试BAT通关手册》,覆盖了Java核心技术、JVM、Java并发、SSM、微服务、数据库、数据结构等等。
获取方式:点“在看”,关注公众号并回复 666 领取,更多内容陆续奉上。
明天见(。・ω・。)ノ♡
我司“双11”限流方案,进来抄作业!相关推荐
- 微服务架构服务限流方案详解
话说在 Spring Cloud Gateway 问世之前,Spring Cloud 的微服务世界里,网关一定非 Netflix Zuul 莫属.但是由于 Zuul 1.x 存在的一些问题,比如阻塞式 ...
- spring gateway 限流持久化_Spring Cloud Gateway网关如何快速实施限流方案?-Part 6
熔断降级 在分布式系统中,网关作为流量的入口,大量请求进入网关,向后端远程系统或服务发起调用,后端服务不可避免的会产生调用失败(超时或者异常),失败时不能让请求堆积在网关上,需要快速失败并返回回去,这 ...
- mysql数据库限流方案_用于对MySQL数据库的并发操作进行控制的方法及装置的制造方法_3...
的数据库操作特点,预先设置的所述第一限流类型可以不同于本实施例中的设置,同样可以实现本申请的技术方案,也在本申请的保护范围之内. [0103]步骤102-3:判断MySQL数据库的threads_ru ...
- 分布式高并发服务三种常用限流方案简介
以下文章来源于技术岁月 ,作者贺鹏Kavin 在高并发大流量系统中,由于并发大造成服务资源不足,负载过高,进而引发致一系列问题,这里的流量一般都是突发性的,由于系统准备不足,很难短期扩容来应对 ,进行 ...
- 常用限流方案的设计和实现
为了保证在业务高峰期,线上系统也能保证一定的弹性和稳定性,最有效的方案就是进行服务降级了,而限流就是降级系统最常采用的方案之一. 限流即流量限制,或者高大上一点,叫做流量整形,限流的目的是在遇到流量高 ...
- 我们公司使用了 5 年的系统限流方案 ,从实现到部署实战详解,稳的一B
前言 最近几年,随着微服务的流行,服务和服务之间的依赖越来越强,调用关系越来越复杂,服务和服务之间的稳定性越来越重要.在遇到突发的请求量激增,恶意的用户访问,亦或请求频率过高给下游服务带来较大压力时, ...
- 阿里巴巴2020年双11: Flink流批一体化真的来了 (Flink Forward 2020 PPT)
随着双11在11月12日午夜结束,2020 双十一购物节的商品总销售额(GMV)达到741亿美元.在Apache Flink的支持下,整个节日期间,GMV数值将稳定地实时显示在我们的大屏幕中.此外, ...
- HDFS的读写限流方案
我们的集群有的时候一跑几个大的任务,就会把机房网络带宽瞬间打满,导致线上部分服务抖动.所以我们就想到了在HDFS对普通读写的限流.所以说,本文可以实质上说是一篇总结报告,阐述了方案的设想,实现以及结果 ...
- nginx限流方案的实现(三种方式)
通过查看nginx官方文档,小弟查看到了三种nginx限流方式. 1.limit_conn_zone 2.limit_req_zone 3.ngx_http_upstream_module 前两种只能 ...
最新文章
- 算法学习--Day5
- 计算机解题报告,计算机题目33题(附带题解)精选.doc
- 数据库平时错误和使用经验的总结
- 【Git、GitHub、GitLab】十 将git仓库备份到本地
- Python爬取上交所年报下载并转TXT
- React Native微信分享
- 修改Samba服务的监听端口
- MySQL最重要的日志-binlog详解
- vscode的下载、安装
- 【MapReduce】MapReduce读写MySQL数据
- 个人博客后台管理系统
- 新邮政法规定:邮政企业对平常邮件损失不赔偿
- 一张图认识Python(附基本语法总结)
- Oracle 查询技巧与优化(一) 单表查询与排序
- 关于2021/12/17国内bing不能正常访问的解决方法。
- 服务器BIOS装光盘装系统设置,如何用光盘启动安装系统---BIOS设置
- Few-Shot Learning
- Nginx OCSP
- 三分钟了解MySQL慢查询
- 18650锂电池参数、充放电时间计算详解
热门文章
- Ubuntu 18.04安装Matlab 2018
- java 视频分辨率_java – Blackberry:如何在录制前设置视频分辨率
- putty如何安装mysql_使用Linux 安装MySQL
- macaca之app-inspector
- Linux Shell高级技巧(目录)
- JavaWeb基础—JSP
- 运行报表时提示输入用户名和密码
- 客户端如何连接 DataSnap Server 调用服务的方法
- jQuery学习笔记(一)
- 黑马程序员___Java基础[02-Java基础语法](一)