从京东618秒杀聊聊秒杀限流的多种实现!
前言
俗话说的好,冰冻三尺非一日之寒,滴水穿石非一日之功,罗马也不是一天就建成的。两周前秒杀案例初步成型,分享到了中国最大的同性交友网站-码云。同时也收到了不少小伙伴的建议和投诉。我从不认为分布式、集群、秒杀这些就应该是大厂的专利,在互联网的今天无论什么时候都要时刻武装自己,只有这样,也许你的春天就在明天。
在开发秒杀系统案例的过程中,前面主要分享了队列、缓存、锁和分布式锁以及静态化等等。缓存的目的是为了提升系统访问速度和增强系统的处理能力;分布式锁解决了集群下数据的安全一致性问题;静态化无疑是减轻了缓存以及DB层的压力。
限流
然而再牛逼的机器,再优化的设计,对于特殊场景我们也是要特殊处理的。就拿秒杀来说,可能会有百万级别的用户进行抢购,而商品数量远远小于用户数量。如果这些请求都进入队列或者查询缓存,对于最终结果没有任何意义,徒增后台华丽的数据。对此,为了减少资源浪费,减轻后端压力,我们还需要对秒杀进行限流,只需保障部分用户服务正常即可。
就秒杀接口来说,当访问频率或者并发请求超过其承受范围的时候,这时候我们就要考虑限流来保证接口的可用性,以防止非预期的请求对系统压力过大而引起的系统瘫痪。通常的策略就是拒绝多余的访问,或者让多余的访问排队等待服务。
限流算法
任何限流都不是漫无目的的,也不是一个开关就可以解决的问题,常用的限流算法有:令牌桶,漏桶。
令牌桶
令牌桶算法是网络流量整形(Traffic Shaping)和速率限制(Rate Limiting)中最常使用的一种算法。典型情况下,令牌桶算法用来控制发送到网络上的数据的数目,并允许突发数据的发送(百科)。
在秒杀活动中,用户的请求速率是不固定的,这里我们假定为10r/s,令牌按照5个每秒的速率放入令牌桶,桶中最多存放20个令牌。仔细想想,是不是总有那么一部分请求被丢弃。
漏桶
漏桶算法的主要目的是控制数据注入到网络的速率,平滑网络上的突发流量。漏桶算法提供了一种机制,通过它,突发流量可以被整形以便为网络提供一个稳定的流量(百科)。
令牌桶是无论你流入速率多大,我都按照既定的速率去处理,如果桶满则拒绝服务。
应用限流
Tomcat
在Tomcat容器中,我们可以通过自定义线程池,配置最大连接数,请求处理队列等参数来达到限流的目的。
Tomcat默认使用自带的连接池,这里我们也可以自定义实现,打开/conf/server.xml文件,在Connector之前配置一个线程池:
<Executor name="tomcatThreadPool"
namePrefix="tomcatThreadPool-"
maxThreads="1000"
maxIdleTime="300000"
minSpareThreads="200"/>
name:共享线程池的名字。这是Connector为了共享线程池要引用的名字,该名字必须唯一。默认值:None;
namePrefix:在JVM上,每个运行线程都可以有一个name 字符串。这一属性为线程池中每个线程的name字符串设置了一个前缀,Tomcat将把线程号追加到这一前缀的后面。默认值:tomcat-exec-;
maxThreads:该线程池可以容纳的最大线程数。默认值:200;
maxIdleTime:在Tomcat关闭一个空闲线程之前,允许空闲线程持续的时间(以毫秒为单位)。只有当前活跃的线程数大于minSpareThread的值,才会关闭空闲线程。默认值:60000(一分钟)。
minSpareThreads:Tomcat应该始终打开的最小不活跃线程数。默认值:25。
配置Connector
<Connector executor="tomcatThreadPool"
port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443"
minProcessors="5"
maxProcessors="75"
acceptCount="1000"/>
executor:表示使用该参数值对应的线程池;
minProcessors:服务器启动时创建的处理请求的线程数;
maxProcessors:最大可以创建的处理请求的线程数;
acceptCount:指定当所有可以使用的处理请求的线程数都被使用时,可以放到处理队列中的请求数,超过这个数的请求将不予处理。
API限流
秒杀活动中,接口的请求量会是平时的数百倍甚至数千倍,从而有可能导致接口不可用,并引发连锁反应导致整个系统崩溃,甚至有可能会影响到其它服务。
那么如何应对这种突然事件呢?这里我们采用开源工具包guava提供的限流工具类RateLimiter进行API限流,该类基于"令牌桶算法",开箱即用。
自定义定义注解
/**
* 自定义注解 限流
*/
@Target({ElementType.PARAMETER, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface ServiceLimit {
String description() default "";
}
自定义切面
/**
* 限流 AOP
*/
@Component
@Scope
@Aspect
public class LimitAspect {
//每秒只发出100个令牌,此处是单进程服务的限流,内部采用令牌捅算法实现
private static RateLimiter rateLimiter = RateLimiter.create(100.0);
//Service层切点 限流
@Pointcut("@annotation(com.itstyle.seckill.common.aop.ServiceLimit)")
public void ServiceAspect() {
}
@Around("ServiceAspect()")
public Object around(ProceedingJoinPoint joinPoint) {
Boolean flag = rateLimiter.tryAcquire();
Object obj = null;
try {
if(flag){
obj = joinPoint.proceed();
}
} catch (Throwable e) {
e.printStackTrace();
}
return obj;
}
}
业务实现:
@Override
@ServiceLimit
@Transactional
public Result startSeckil(long seckillId, long userId) {
//省略部分业务代码,详见秒杀源码
}
分布式限流
Nginx
如何使用Nginx实现基本的限流,比如单个IP限制每秒访问50次。通过Nginx限流模块,我们可以设置一旦并发连接数超过我们的设置,将返回503错误给客户端。
配置nginx.conf
#统一在http域中进行配置
#限制请求
limit_req_zone $binary_remote_addr $uri zone=api_read:20m rate=50r/s;
#按ip配置一个连接 zone
limit_conn_zone $binary_remote_addr zone=perip_conn:10m;
#按server配置一个连接 zone
limit_conn_zone $server_name zone=perserver_conn:100m;
server {
listen 80;
server_name seckill.52itstyle.com;
index index.jsp;
location / {
#请求限流排队通过 burst默认是0
limit_req zone=api_read burst=5;
#连接数限制,每个IP并发请求为2
limit_conn perip_conn 2;
#服务所限制的连接数(即限制了该server并发连接数量)
limit_conn perserver_conn 1000;
#连接限速
limit_rate 100k;
proxy_pass http://seckill;
}
}
upstream seckill {
fair;
server 172.16.1.120:8080 weight=1 max_fails=2 fail_timeout=30s;
server 172.16.1.130:8080 weight=1 max_fails=2 fail_timeout=30s;
}
配置说明
imitconnzone
是针对每个IP定义一个存储session状态的容器。这个示例中定义了一个100m的容器,按照32bytes/session,可以处理3200000个session。
limit_rate 300k;
对每个连接限速300k. 注意,这里是对连接限速,而不是对IP限速。如果一个IP允许两个并发连接,那么这个IP就是限速limit_rate×2。
burst=5;
这相当于桶的大小,如果某个请求超过了系统处理速度,会被放入桶中,等待被处理。如果桶满了,那么抱歉,请求直接返回503,客户端得到一个服务器忙的响应。如果系统处理请求的速度比较慢,桶里的请求也不能一直待在里面,如果超过一定时间,也是会被直接退回,返回服务器忙的响应。
OpenResty
背影有没有很熟悉,对这就是那个直呼理解万岁老罗,2015年老罗在锤子科技T2发布会上将门票收入捐赠给了 OpenResty,也相信老罗是个有情怀的胖子。
这里我们使用 OpenResty 开源的限流方案,测试案例使用OpenResty1.13.6.1最新版本,自带lua-resty-limit-traffic模块以及案例 ,实现起来更为方便。
限制接口总并发数/请求数
秒杀活动中,由于突发流量暴增,有可能会影响整个系统的稳定性从而造成崩溃,这时候我们就要限制秒杀接口的总并发数/请求数。
这里我们采用 lua-resty-limit-traffic中的resty.limit.count模块实现,由于文章篇幅具体代码参见源码openresty/lua/limit_count.lua。
限制接口时间窗请求数
秒杀场景下,有时候并都是人肉鼠标,比如12306的抢票软件,软件刷票可比人肉鼠标快多了。此时我们就要对客户端单位时间内的请求数进行限制,以至于刷票不是那么猖獗。当然了道高一尺魔高一丈,抢票软件总是会有办法绕开你的防线,从另一方面讲也促进了技术的进步。
这里我们采用 lua-resty-limit-traffic中的resty.limit.conn模块实现,具体代码参见源码openresty/lua/limit_conn.lua。
平滑限制接口请求数
之前的限流方式允许突发流量,也就是说瞬时流量都会被允许。突然流量如果不加以限制会影响整个系统的稳定性,因此在秒杀场景中需要对请求整形为平均速率处理,即20r/s。
这里我们采用 lua-resty-limit-traffic 中的resty.limit.req 模块实现漏桶限流和令牌桶限流。
其实漏桶和令牌桶根本的区别就是,如何处理超过请求速率的请求。漏桶会把请求放入队列中去等待均速处理,队列满则拒绝服务;令牌桶在桶容量允许的情况下直接处理这些突发请求。
漏桶
桶容量大于零,并且是延迟模式。如果桶没满,则进入请求队列以固定速率等待处理,否则请求被拒绝。
令牌桶
桶容量大于零,并且是非延迟模式。如果桶中存在令牌,则允许突发流量,否则请求被拒绝。
压测
为了测试以上配置效果,我们采用AB压测,Linux下执行以下命令即可:
# 安装
yum -y install httpd-tools
# 查看ab版本
ab -v
# 查看帮助
ab --help
测试命令:
ab -n 1000 -c 100 http://127.0.0.1/
测试结果:
Server Software: openresty/1.13.6.1 #服务器软件
Server Hostname: 127.0.0.1 #IP
Server Port: 80 #请求端口号
Document Path: / #文件路径
Document Length: 12 bytes #页面字节数
Concurrency Level: 100 #请求的并发数
Time taken for tests: 4.999 seconds #总访问时间
Complete requests: 1000 #总请求树
Failed requests: 0 #请求失败数量
Write errors: 0
Total transferred: 140000 bytes #请求总数据大小
HTML transferred: 12000 bytes #html页面实际总字节数
Requests per second: 200.06 [#/sec] (mean) #每秒多少请求,这个是非常重要的参数数值,服务器的吞吐量
Time per request: 499.857 [ms] (mean) #用户平均请求等待时间
Time per request: 4.999 [ms] (mean, across all concurrent requests) # 服务器平均处理时间,也就是服务器吞吐量的倒数
Transfer rate: 27.35 [Kbytes/sec] received #每秒获取的数据长度
Connection Times (ms)
min mean[+/-sd] median max
Connect: 0 0 0.8 0 4
Processing: 5 474 89.1 500 501
Waiting: 2 474 89.2 500 501
Total: 9 475 88.4 500 501
Percentage of the requests served within a certain time (ms)
50% 500
66% 500
75% 500
80% 500
90% 501
95% 501
98% 501
99% 501
100% 501 (longest request)
秒杀项目源码:从0到1构建分布式秒杀系统
总结
以上限流方案,只是针对此次秒杀案例做一个简单的小结,大家也不要刻意区分那种方案的好坏,只要适合业务场景就是最好的。
点击图片查看更多推荐内容
↓↓↓
中小企业对Spring Cloud微服务的一些思考!
开发中我们需要遵循的几个设计原则!
分布式之消息队列复习精讲!
MySQL到底有多少种日志类型需要我们记住的!
从京东618秒杀聊聊秒杀限流的多种实现!相关推荐
- 秒杀限制人群,如何设计秒杀服务的限流策略?
对于秒杀业务,大家应该比较熟悉了.比如,"某商品原价 1299 元, 双十一整点秒杀价仅 500 元,限量 100 件,先到先得" 等等.通过这段文案我们能够发现,参与秒杀活动商品 ...
- 如何设计秒杀服务器的限流策略
如果平时系统的访问量只有一万,而最大承受限制为五万,在秒杀时刻的瞬间,访问量突然增加到100W,此事系统一定会因访问量过大而宕机,此时就应该设计一个限流策略,使服务器能接收和处理的请求减少. 秒杀限流 ...
- 聊聊高并发系统之限流特技-1
在开发高并发系统时有三把利器用来保护系统:缓存.降级和限流. 缓存的目的是提升系统访问速度和增大系统能处理的容量,可谓是抗高并发流量的银弹:而降级是当服务出问题或者影响到核心流程的性能则需要暂时屏蔽掉 ...
- 高并发系统之限流特技
转载至:http://blog.csdn.net/g_hongjin/article/details/51649246 在开发高并发系统时有三把利器用来保护系统:缓存.降级和限流.缓存的目的是提升系统 ...
- 分布式限流的解决方案
业务背景介绍 对于web应用的限流,光看标题,似乎过于抽象,难以理解,那我们还是以具体的某一个应用场景来引入这个话题吧. 在日常生活中,我们肯定收到过不少不少这样的短信,"双11约吗?, ...
- 高并发解决方案(缓存、降级、限流)之限流笔记
转载自:jinnianshilongnian 高并发系统时有三把利器用来保护系统:缓存.降级和限流.缓存的目的是提升系统访问速度和增大系统能处理的容量,可谓是抗高并发流量的银弹:而降级是当服务出问题或 ...
- 【SpringBoot商城秒杀系统秒杀优化学习笔记】
课程介绍 什么是秒杀 秒杀场景一般会在电商网站举行一些活动或者节假日在12306网站上抢票时遇到.对于电商网站中一些稀缺或者特价商品,电商网站一般会在约定时间点对其进行限量销售,因为这些商品的特殊性, ...
- 服务溶断、降级、限流
服务熔断 在介绍熔断机制之前,我们需要了解微服务的雪崩效应.在微服务架构中,微服务是完成一个单一的业务功能,这样做的好处是可以做到解耦,每个微服务可以独立演进.但是,一个应用可能会有多个微服务组成,微 ...
- 服务溶断、降级、限流(1):概念
服务熔断 在介绍熔断机制之前,我们需要了解微服务的雪崩效应.在微服务架构中,微服务是完成一个单一的业务功能,这样做的好处是可以做到解耦,每个微服务可以独立演进.但是,一个应用可能会有多个微服务组成,微 ...
- 分布式限流算法及方案介绍
欢迎访问原文地址来阅读最新版本 转载请注明出处:kang.fun/distributed-ratelimiter 个人博客:kang.fun 业务场景 现代互联网很多业务场景,比如秒杀.下单.查询商品 ...
最新文章
- matplotlib画图绘制辅助线
- 鸡尾酒排序算法c语言,[golang] 数据结构-鸡尾酒排序
- 暗黑模式盛行,如何设计更好的深色UI ?暗黑模式盛行,如何设计更好的深色UI ?
- 【性能优化】增量检查点
- 开源及第三方软件管理体系
- 单片机程序编写常使用的程序架构
- 微服务业务日志收集方案
- 【北京圣思园学习笔记】第01讲:Java概述
- 【Unity】用2D流体实现在水中添加染料的效果
- 第03章-二进制、八进制、十进制、十六进制之间的转换-深博-专题视频课程
- 2019ug最新版本是多少_重磅!UGNX将在2019年发布最新版本!也将是最后一个版本!新功能令人意想不到!...
- 余压监控系统在住宅小区的应用方案
- 【转】MT7688学习笔记(6)——OpenWrt下串口编程
- 微信朋友圈得内容可以爬取吗?看完这篇你心里就有底了
- Leetcode 1823 找出游戏的获胜者 (约瑟夫环问题)
- 这哥们儿的日志让我的心情好得一塌糊涂(ZZ)
- MyEclipse7.02注册码
- python的标准随机数生成器模块是_Python的标准随机数生成器模块是
- 计算机页面格式和编排,计算机基础教案word排版页面格式设置.doc
- Opencv 6种模板匹配