限流

再牛逼的机器，再优化的设计，对于特殊场景我们也是要特殊处理的。就拿秒杀来说，可能会有百万级别的用户进行抢购，而商品数量远远小于用户数量。如果这些请求都进入队列或者查询缓存，对于最终结果没有任何意义，徒增后台华丽的数据。对此，为了减少资源浪费，减轻后端压力，我们还需要对秒杀进行限流，只需保障部分用户服务正常即可。

就秒杀接口来说，当访问频率或者并发请求超过其承受范围的时候，这时候我们就要考虑限流来保证接口的可用性，以防止非预期的请求对系统压力过大而引起的系统瘫痪。通常的策略就是拒绝多余的访问，或者让多余的访问排队等待服务。

限流算法

任何限流都不是漫无目的的，也不是一个开关就可以解决的问题，常用的限流算法有：令牌桶，漏桶。

令牌桶

令牌桶算法是网络流量整形（Traffic Shaping）和速率限制（Rate Limiting）中最常使用的一种算法。典型情况下，令牌桶算法用来控制发送到网络上的数据的数目，并允许突发数据的发送(百科)。

在秒杀活动中，用户的请求速率是不固定的，这里我们假定为10r/s，令牌按照5个每秒的速率放入令牌桶，桶中最多存放20个令牌。仔细想想，是不是总有那么一部分请求被丢弃。

漏桶

漏桶算法的主要目的是控制数据注入到网络的速率，平滑网络上的突发流量。漏桶算法提供了一种机制，通过它，突发流量可以被整形以便为网络提供一个稳定的流量(百科)。

令牌桶是无论你流入速率多大，我都按照既定的速率去处理，如果桶满则拒绝服务。

应用限流

Tomcat

在Tomcat容器中，我们可以通过自定义线程池，配置最大连接数，请求处理队列等参数来达到限流的目的。

Tomcat默认使用自带的连接池，这里我们也可以自定义实现，打开/conf/server.xml文件，在Connector之前配置一个线程池：

  1. <Executor name="tomcatThreadPool"

  2.        namePrefix="tomcatThreadPool-"

  3.        maxThreads="1000"

  4.        maxIdleTime="300000"

  5.        minSpareThreads="200"/>

  • name：共享线程池的名字。这是Connector为了共享线程池要引用的名字，该名字必须唯一。默认值：None；

  • namePrefix:在JVM上，每个运行线程都可以有一个name 字符串。这一属性为线程池中每个线程的name字符串设置了一个前缀，Tomcat将把线程号追加到这一前缀的后面。默认值：tomcat-exec-；

  • maxThreads：该线程池可以容纳的最大线程数。默认值：200；

  • maxIdleTime：在Tomcat关闭一个空闲线程之前，允许空闲线程持续的时间(以毫秒为单位)。只有当前活跃的线程数大于minSpareThread的值，才会关闭空闲线程。默认值：60000(一分钟)。

  • minSpareThreads：Tomcat应该始终打开的最小不活跃线程数。默认值：25。

配置Connector

  1. <Connector executor="tomcatThreadPool"

  2.           port="8080" protocol="HTTP/1.1"

  3.           connectionTimeout="20000"

  4.           redirectPort="8443"

  5.           minProcessors="5"

  6.           maxProcessors="75"

  7.           acceptCount="1000"/>

  • executor：表示使用该参数值对应的线程池；

  • minProcessors：服务器启动时创建的处理请求的线程数；

  • maxProcessors：最大可以创建的处理请求的线程数；

  • acceptCount：指定当所有可以使用的处理请求的线程数都被使用时，可以放到处理队列中的请求数，超过这个数的请求将不予处理。

API限流

秒杀活动中，接口的请求量会是平时的数百倍甚至数千倍，从而有可能导致接口不可用，并引发连锁反应导致整个系统崩溃，甚至有可能会影响到其它服务。

那么如何应对这种突然事件呢？这里我们采用开源工具包guava提供的限流工具类RateLimiter进行API限流，该类基于"令牌桶算法"，开箱即用。

自定义定义注解

  1. /**

  2. * 自定义注解  限流

  3. */

  4. @Target({ElementType.PARAMETER, ElementType.METHOD})

  5. @Retention(RetentionPolicy.RUNTIME)

  6. @Documented

  7. public  @interface ServiceLimit {

  8.     String description()  default "";

  9. }

  自定义切面

  1. /**

  2. * 限流 AOP

  3. */

  4. @Component

  5. @Scope

  6. @Aspect

  7. public class LimitAspect {

  8.    //每秒只发出100个令牌，此处是单进程服务的限流，内部采用令牌捅算法实现

  9.    private static   RateLimiter rateLimiter = RateLimiter.create(100.0);

  10.  

  11.    //Service层切点  限流

  12.    @Pointcut("@annotation(com.itstyle.seckill.common.aop.ServiceLimit)")  

  13.    public void ServiceAspect() {

  14.  

  15.    }

  16.  

  17.    @Around("ServiceAspect()")

  18.    public  Object around(ProceedingJoinPoint joinPoint) {

  19.        Boolean flag = rateLimiter.tryAcquire();

  20.        Object obj = null;

  21.        try {

  22.            if(flag){

  23.                obj = joinPoint.proceed();

  24.            }

  25.        } catch (Throwable e) {

  26.            e.printStackTrace();

  27.        }

  28.        return obj;

  29.    }

  30. }

业务实现：

  1. @Override

  2. @ServiceLimit

  3. @Transactional

  4. public Result startSeckil(long seckillId, long userId) {

  5.    //省略部分业务代码，详见秒杀源码

  6. }

分布式限流

Nginx

如何使用Nginx实现基本的限流，比如单个IP限制每秒访问50次。通过Nginx限流模块，我们可以设置一旦并发连接数超过我们的设置，将返回503错误给客户端。

配置nginx.conf

 

  1. #统一在http域中进行配置

  2. #限制请求

  3. limit_req_zone $binary_remote_addr $uri zone=api_read:20m rate=50r/s;

  4. #按ip配置一个连接 zone

  5. limit_conn_zone $binary_remote_addr zone=perip_conn:10m;

  6. #按server配置一个连接 zone

  7. limit_conn_zone $server_name zone=perserver_conn:100m;

  8. server {

  9.        listen       80;

  10.        server_name  seckill.52itstyle.com;

  11.        index index.jsp;

  12.        location / {

  13.              #请求限流排队通过 burst默认是0

  14.              limit_req zone=api_read burst=5;

  15.              #连接数限制,每个IP并发请求为2

  16.              limit_conn perip_conn 2;

  17.              #服务所限制的连接数(即限制了该server并发连接数量)

  18.              limit_conn perserver_conn 1000;

  19.              #连接限速

  20.              limit_rate 100k;

  21.              proxy_pass      http://seckill;

  22.        }

  23. }

  24. upstream seckill {

  25.        fair;

  26.        server  172.16.1.120:8080 weight=1  max_fails=2 fail_timeout=30s;

  27.        server  172.16.1.130:8080 weight=1  max_fails=2 fail_timeout=30s;

  28. }

配置说明

imitconnzone

是针对每个IP定义一个存储session状态的容器。这个示例中定义了一个100m的容器，按照32bytes/session，可以处理3200000个session。

limit_rate 300k;

对每个连接限速300k. 注意，这里是对连接限速，而不是对IP限速。如果一个IP允许两个并发连接，那么这个IP就是限速limit_rate×2。

burst=5；

这相当于桶的大小，如果某个请求超过了系统处理速度，会被放入桶中，等待被处理。如果桶满了，那么抱歉，请求直接返回503，客户端得到一个服务器忙的响应。如果系统处理请求的速度比较慢，桶里的请求也不能一直待在里面，如果超过一定时间，也是会被直接退回，返回服务器忙的响应。

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下执行以下命令即可：

  1. # 安装

  2. yum -y install httpd-tools

  3. # 查看ab版本

  4. ab -v

  5. # 查看帮助

  6. ab --help

测试命令：

 

  1. ab -n 1000 -c 100 http://127.0.0.1/

测试结果：

 

  1. Server Software:        openresty/1.13.6.1  #服务器软件

  2. Server Hostname:        127.0.0.1     #IP

  3. Server Port:            80            #请求端口号

  4.  

  5. Document Path:          /             #文件路径

  6. Document Length:        12 bytes      #页面字节数

  7.  

  8. Concurrency Level:      100           #请求的并发数

  9. Time taken for tests:   4.999 seconds #总访问时间

  10. Complete requests:      1000          #总请求树

  11. Failed requests:        0             #请求失败数量

  12. Write errors:           0

  13. Total transferred:      140000 bytes  #请求总数据大小

  14. HTML transferred:       12000 bytes   #html页面实际总字节数

  15. Requests per second:    200.06 [#/sec] (mean) #每秒多少请求，这个是非常重要的参数数值，服务器的吞吐量

  16. Time per request:       499.857 [ms] (mean) #用户平均请求等待时间

  17. Time per request:       4.999 [ms] (mean, across all concurrent requests)  # 服务器平均处理时间，也就是服务器吞吐量的倒数

  18. Transfer rate:          27.35 [Kbytes/sec] received #每秒获取的数据长度

  19.  

  20. Connection Times (ms)

  21.              min  mean[+/-sd] median   max

  22. Connect:        0    0   0.8      0       4

  23. Processing:     5  474  89.1    500     501

  24. Waiting:        2  474  89.2    500     501

  25. Total:          9  475  88.4    500     501

  26.  

  27. Percentage of the requests served within a certain time (ms)

  28.  50%    500

  29.  66%    500

  30.  75%    500

  31.  80%    500

  32.  90%    501

  33.  95%    501

  34.  98%    501

  35.  99%    501

  36. 100%    501 (longest request)

总结

以上限流方案，只是针对此次秒杀案例做一个简单的小结，大家也不要刻意区分那种方案的好坏，只要适合业务场景就是最好的。

Logo
向您推荐>>Eolink开发者社区

权威｜前沿｜技术｜干货｜国内首个API全生命周期开发者社区

更多推荐

ELK实现containerd的容器日志采集展示【基于logging的全栈监测】

企业级ELK Stack构建介绍

avatar 云原生

深入理解 Mocha 测试框架：从零实现一个 Mocha

前言什么是自动化测试自动化测试在很多团队中都是Devops环节中很难执行起来的一个环节，主要原因在于测试代码的编写工作很难抽象，99%的场景都需要和业务强绑定，而且写测试代码的编写工作量往往比编写实际业务代码的工作量更多。在一些很多业务场景中投入产出比很低，适合写自动化测试的应该是那些中长期业务以及一些诸如组件一样的基础库。自动化测试是个比较大的概念，其中分类也比较多，比如单元测试，端对端测试，集

avatar 云原生

(20200916 Solved)docker-compose up创建容器自动退出

问题描述如题，创建容器后自动退出了。并且docker start container无效解决方案原因是缺失了控制终端的配置，需要在docker-compose.yml中增加tty:true ，有时候这样也不行，需要再增加一个command:/bin/bash，命令不一定是这个，需要是一个不会退出的命令，然后用-d后台启动容器。Referencesdocker-compose启动容器后自动退出...

avatar 云原生