nginx配置如何设置接口失效时间 nginx接口限流

 

为什么要互联网项目要限流

在开发高并发系统时有三把利器用来保护系统：缓存、降级和限流。缓存的目的是提升系统访问速度和增大系统能处理的容量，可谓是抗高并发流量的银弹；而降级是当服务出问题或者影响到核心流程的性能则需要暂时屏蔽掉，待高峰或者问题解决后再打开；而有些场景并不能用缓存和降级来解决，比如稀缺资源（秒杀、抢购）、写服务（如评论、下单）、频繁的复杂查询（评论的最后几页），因此需有一种手段来限制这些场景的并发/请求量，即限流。

互联网雪崩效应解决方案

服务降级: 在高并发的情况， 防止用户一直等待，直接返回一个友好的错误提示给客户端。

服务熔断：在高并发的情况，一旦达到服务最大的承受极限，直接拒绝访问，使用服务降级。

服务隔离: 使用服务隔离方式解决服务雪崩效应

服务限流: 在高并发的情况，一旦服务承受不了使用服务限流机制（计时器（滑动窗口计数）、漏桶算法、令牌桶（Restlimite））

 

高并发限流解决方案

高并发限流解决方案限流算法(令牌桶、漏桶、计数器)

限流算法

常见的限流算法有：令牌桶、漏桶。计数器也可以进行粗暴限流实现。

计数器

  它是限流算法中最简单最容易的一种算法，比如我们要求某一个接口，1分钟内的请求不能超过10次，我们可以在开始时设置一个计数器，每次请求，该计数器+1；如果该计数器的值大于10并且与第一次请求的时间间隔在1分钟内，那么说明请求过多，如果该请求与第一次请求的时间间隔大于1分钟，并且该计数器的值还在限流范围内，那么重置该计数器

这种方式有个弊端，可能会产生临界的问题，见上图，假如第59秒进行了10个请求，61秒的时候又进行了10个请求，这20个请求都会执行成功，如果在临界的时候突然有大量请求，可能会违背定义固定速率。解决方法是使用滑动窗口计数器。

 

/**

 * 功能说明: 纯手写计数器方式<br>

 */

public class LimitService {



      private int limtCount = 60;// 限制最大访问的容量

      AtomicInteger atomicInteger = new AtomicInteger(0); // 每秒钟 实际请求的数量

      private long start = System.currentTimeMillis();// 获取当前系统时间

      private int interval = 60;// 间隔时间60秒



      public boolean acquire() {

            long newTime = System.currentTimeMillis();

            if (newTime > (start + interval)) {

                  // 判断是否是一个周期

                  start = newTime;

                  atomicInteger.set(0); // 清理为0

                  return true;

            }

            atomicInteger.incrementAndGet();// i++;

            return atomicInteger.get() <= limtCount;

      }



      static LimitService limitService = new LimitService();



      public static void main(String[] args) {



            ExecutorService newCachedThreadPool = Executors.newCachedThreadPool();

            for (int i = 1; i < 100; i++) {

                  final int tempI = i;

                  newCachedThreadPool.execute(new Runnable() {



                       public void run() {

                             if (limitService.acquire()) {

                                   System.out.println("你没有被限流,可以正常访问逻辑 i:" + tempI);

                             } else {

                                   System.out.println("你已经被限流呢  i:" + tempI);

                             }

                       }

                  });

            }

      }



}

滑动窗口计数

 

 

滑动窗口计数有很多使用场景，比如说限流防止系统雪崩。相比计数实现，滑动窗口实现会更加平滑，能自动消除毛刺。

滑动窗口原理是在每次有访问进来时，先判断前 N 个单位时间内的总访问量是否超过了设置的阈值，并对当前时间片上的请求数 +1。

  令牌桶算法

令牌桶算法是一个存放固定容量令牌的桶，按照固定速率往桶里添加令牌。令牌桶算法的描述如下：

假设限制2r/s(每秒钟放2个令牌)，则按照500毫秒的固定速率往桶中添加令牌；

桶中最多存放b个令牌，当桶满时，新添加的令牌被丢弃或拒绝；

当一个n个字节大小的数据包到达，将从桶中删除n个令牌，接着数据包被发送到网络上；

如果桶中的令牌不足n个，则不会删除令牌，且该数据包将被限流（要么丢弃，要么缓冲区等待）。

 

使用RateLimiter实现令牌桶限流

RateLimiter是guava提供的基于令牌桶算法的实现类，可以非常简单的完成限流特技，并且根据系统的实际情况来调整生成token的速率。

通常可应用于抢购限流防止冲垮系统；限制某接口、服务单位时间内的访问量，譬如一些第三方服务会对用户访问量进行限制；限制网速，单位时间内只允许上传下载多少字节等。

下面来看一些简单的实践，需要先引入guava的maven依赖。

 

<parent>

            <groupId>org.springframework.boot</groupId>

            <artifactId>spring-boot-starter-parent</artifactId>

            <version>2.0.0.RELEASE</version>

      </parent>

      <dependencies>

            <dependency>

                  <groupId>org.springframework.boot</groupId>

                  <artifactId>spring-boot-starter-web</artifactId>

            </dependency>

            <dependency>

                  <groupId>com.google.guava</groupId>

                  <artifactId>guava</artifactId>

                  <version>25.1-jre</version>

            </dependency>

      </dependencies>

使用RateLimiter 实现令牌桶算法

/**

 * 功能说明:使用RateLimiter 实现令牌桶算法

 *

 */

@RestController

public class IndexController {

      @Autowired

      private OrderService orderService;

      // 解释：1.0 表示 每秒中生成1个令牌存放在桶中

      RateLimiter rateLimiter = RateLimiter.create(1.0);



      // 下单请求

      @RequestMapping("/order")

      public String order() {

            // 1.限流判断

            // 如果在500秒内 没有获取不到令牌的话，则会一直等待

            System.out.println("生成令牌等待时间:" + rateLimiter.acquire());

            boolean acquire = rateLimiter.tryAcquire(500, TimeUnit.MILLISECONDS);

            if (!acquire) {

                  System.out.println("你在怎么抢，也抢不到，因为会一直等待的，你先放弃吧！");

                  return "你在怎么抢，也抢不到，因为会一直等待的，你先放弃吧！";

            }



            // 2.如果没有达到限流的要求,直接调用订单接口

            boolean isOrderAdd = orderService.addOrder();

            if (isOrderAdd) {

                  return "恭喜您,抢购成功!";

            }

            return "抢购失败!";

      }



}

 

漏桶算法

漏桶作为计量工具（The Leaky Bucket Algorithm as a Meter）时，可以用于流量整形（Traffic Shaping）和流量控制（TrafficPolicing），漏桶算法的描述如下：

一个固定容量的漏桶，按照常量固定速率流出水滴；

如果桶是空的，则不需流出水滴；

可以以任意速率流入水滴到漏桶；

如果流入水滴超出了桶的容量，则流入的水滴溢出了（被丢弃），而漏桶容量是不变的。

令牌桶和漏桶对比：

令牌桶是按照固定速率往桶中添加令牌，请求是否被处理需要看桶中令牌是否足够，当令牌数减为零时则拒绝新的请求；

漏桶则是按照常量固定速率流出请求，流入请求速率任意，当流入的请求数累积到漏桶容量时，则新流入的请求被拒绝；

令牌桶限制的是平均流入速率（允许突发请求，只要有令牌就可以处理，支持一次拿3个令牌，4个令牌），并允许一定程度突发流量；

漏桶限制的是常量流出速率（即流出速率是一个固定常量值，比如都是1的速率流出，而不能一次是1，下次又是2），从而平滑突发流入速率；

令牌桶允许一定程度的突发，而漏桶主要目的是平滑流入速率；

两个算法实现可以一样，但是方向是相反的，对于相同的参数得到的限流效果是一样的。

另外有时候我们还使用计数器来进行限流，主要用来限制总并发数，比如数据库连接池、线程池、秒杀的并发数；只要全局总请求数或者一定时间段的总请求数设定的阀值则进行限流，是简单粗暴的总数量限流，而不是平均速率限流。

 

 

一个固定的漏桶，以常量固定的速率流出水滴。

如果桶中没有水滴的话，则不会流出水滴

如果流入的水滴超过桶中的流量，则流入的水滴可能会发生溢出，溢出的水滴请求是无法访问的，直接调用服务降级方法，桶中的容量是不会发生变化。

 

 

漏桶算法与令牌桶算法区别

      主要区别在于“漏桶算法”能够强行限制数据的传输速率，而“令牌桶算法”在能够限制数据的平均传输速率外，还允许某种程度的突发传输。在“令牌桶算法”中，只要令牌桶中存在令牌，那么就允许突发地传输数据直到达到用户配置的门限，因此它适合于具有突发特性的流量。

 

封装RateLimiter

自定义注解封装RateLimiter.实例:

 

@RequestMapping("/myOrder")

@ExtRateLimiter(value = 10.0, timeOut = 500)

public String myOrder() throws InterruptedException {

            System.out.println("myOrder");

            return "SUCCESS";

}

 

自定义注解

@Target(value = ElementType.METHOD)

@Retention(RetentionPolicy.RUNTIME)

public @interface ExtRateLimiter {

      double value();



      long timeOut();

}

编写AOP

@Aspect

@Component

public class RateLimiterAop {

      // 存放接口是否已经存在

      private static ConcurrentHashMap<String, RateLimiter> rateLimiterMap = new ConcurrentHashMap<String, RateLimiter>();



      @Pointcut("execution(public * com.itmayeidu.api.*.*(..))")

      public void rlAop() {

      }



      @Around("rlAop()")

      public Object doBefore(ProceedingJoinPoint proceedingJoinPoint) throws Throwable {

            MethodSignature signature = (MethodSignature) proceedingJoinPoint.getSignature();

            // 使用Java反射技术获取方法上是否有@ExtRateLimiter注解类

            ExtRateLimiter extRateLimiter = signature.getMethod().getDeclaredAnnotation(ExtRateLimiter.class);

            if (extRateLimiter == null) {

                  // 正常执行方法

                  Object proceed = proceedingJoinPoint.proceed();

                  return proceed;

            }

            // ############获取注解上的参数 配置固定速率 ###############

            // 获取配置的速率

            double value = extRateLimiter.value();

            // 获取等待令牌等待时间

            long timeOut = extRateLimiter.timeOut();

            RateLimiter rateLimiter = getRateLimiter(value, timeOut);

            // 判断令牌桶获取token 是否超时

            boolean tryAcquire = rateLimiter.tryAcquire(timeOut, TimeUnit.MILLISECONDS);

            if (!tryAcquire) {

                  serviceDowng();

                  return null;

            }

            // 获取到令牌,直接执行..

            Object proceed = proceedingJoinPoint.proceed();

            return proceed;



      }



      // 获取RateLimiter对象

      private RateLimiter getRateLimiter(double value, long timeOut) {

            // 获取当前URL

            ServletRequestAttributes attributes = (ServletRequestAttributes) RequestContextHolder.getRequestAttributes();

            HttpServletRequest request = attributes.getRequest();

            String requestURI = request.getRequestURI();

            RateLimiter rateLimiter = null;

            if (!rateLimiterMap.containsKey(requestURI)) {

                  // 开启令牌通限流

                  rateLimiter = RateLimiter.create(value); // 独立线程

                  rateLimiterMap.put(requestURI, rateLimiter);

            } else {

                  rateLimiter = rateLimiterMap.get(requestURI);

            }

            return rateLimiter;

      }



      // 服务降级

      private void serviceDowng() throws IOException {

            // 执行服务降级处理

            System.out.println("执行降级方法,亲,服务器忙！请稍后重试!");

            ServletRequestAttributes attributes = (ServletRequestAttributes) RequestContextHolder.getRequestAttributes();

            HttpServletResponse response = attributes.getResponse();

            response.setHeader("Content-type", "text/html;charset=UTF-8");

            PrintWriter writer = response.getWriter();

            try {

                  writer.println("执行降级方法,亲,服务器忙！请稍后重试!");

            } catch (Exception e) {



            } finally {

                  writer.close();

            }



      }



      public static void main(String[] args) {

            // 使用Java反射技术获取方法上是否有@ExtRateLimiter注解类

            ExtRateLimiter extRateLimiter = IndexController.class.getClass().getAnnotation(ExtRateLimiter.class);

            System.out.println(extRateLimiter);

      }



}

接入层限流

 

接入层通常指请求流量的入口，该层的主要目的有：负载均衡、非法请求过滤、请求聚合、缓存、降级、限流、A/B测试、服务质量监控等等。

Nginx官方版本限制IP的连接和并发分别有两个模块：

• limit_req_zone 用来限制单位时间内的请求数，即速率限制,采用的漏桶算法 "leaky bucket"。
• limit_req_conn 用来限制同一时间连接数，即并发限制。

limit_req_zone 参数配置

Syntax:	limit_req zone=name [burst=number] [nodelay];
Default:	—
Context:	http, server, location

limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;

• 第一个参数：$binary_remote_addr 表示通过remote_addr这个标识来做限制，“binary_”的目的是缩写内存占用量，是限制同一客户端ip地址。
• 第二个参数：zone=one:10m表示生成一个大小为10M，名字为one的内存区域，用来存储访问的频次信息。
• 第三个参数：rate=1r/s表示允许相同标识的客户端的访问频次，这里限制的是每秒1次，还可以有比如30r/m的。

limit_req zone=one burst=5 nodelay;

• 第一个参数：zone=one 设置使用哪个配置区域来做限制，与上面limit_req_zone 里的name对应。
• 第二个参数：burst=5，重点说明一下这个配置，burst爆发的意思，这个配置的意思是设置一个大小为5的缓冲区当有大量请求（爆发）过来时，超过了访问频次限制的请求可以先放到这个缓冲区内。
• 第三个参数：nodelay，如果设置，超过访问频次而且缓冲区也满了的时候就会直接返回503，如果没有设置，则所有请求会等待排队。

例子：

http {
    limit_req_zone $binary_remote_addr zone=one:10m rate=1r/s;
    server {
        location /search/ {
            limit_req zone=one burst=5 nodelay;
        }
}

下面配置可以限制特定UA（比如搜索引擎）的访问：

limit_req_zone  $anti_spider  zone=one:10m   rate=10r/s;
limit_req zone=one burst=100 nodelay;
if ($http_user_agent ~* "googlebot|bingbot|Feedfetcher-Google") {
    set $anti_spider $http_user_agent;
}

其他参数

Syntax:	limit_req_log_level info | notice | warn | error;
Default:	
limit_req_log_level error;
Context:	http, server, location

当服务器由于limit被限速或缓存时，配置写入日志。延迟的记录比拒绝的记录低一个级别。例子：limit_req_log_level notice延迟的的基本是info。

Syntax:	limit_req_status code;
Default:	
limit_req_status 503;
Context:	http, server, location

设置拒绝请求的返回值。值只能设置 400 到 599 之间。

ngx_http_limit_conn_module 参数配置

这个模块用来限制单个IP的请求数。并非所有的连接都被计数。只有在服务器处理了请求并且已经读取了整个请求头时，连接才被计数。

Syntax:	limit_conn zone number;
Default:	—
Context:	http, server, location

limit_conn_zone $binary_remote_addr zone=addr:10m;

server {
    location /download/ {
        limit_conn addr 1;
    }

一次只允许每个IP地址一个连接。

limit_conn_zone $binary_remote_addr zone=perip:10m;
limit_conn_zone $server_name zone=perserver:10m;

server {
    ...
    limit_conn perip 10;
    limit_conn perserver 100;
}

可以配置多个limit_conn指令。例如，以上配置将限制每个客户端IP连接到服务器的数量，同时限制连接到虚拟服务器的总数。

Syntax:	limit_conn_zone key zone=name:size;
Default:	—
Context:	http

limit_conn_zone $binary_remote_addr zone=addr:10m;

在这里，客户端IP地址作为关键。请注意，不是$ remote_addr，而是使用$ binary_remote_addr变量。 $ remote_addr变量的大小可以从7到15个字节不等。存储的状态在32位平台上占用32或64字节的内存，在64位平台上总是占用64字节。对于IPv4地址，$ binary_remote_addr变量的大小始终为4个字节，对于IPv6地址则为16个字节。存储状态在32位平台上始终占用32或64个字节，在64位平台上占用64个字节。一个兆字节的区域可以保持大约32000个32字节的状态或大约16000个64字节的状态。如果区域存储耗尽，服务器会将错误返回给所有其他请求。

Syntax:	limit_conn_log_level info | notice | warn | error;
Default:	
limit_conn_log_level error;
Context:	http, server, location

当服务器限制连接数时，设置所需的日志记录级别。

Syntax:	limit_conn_status code;
Default:	
limit_conn_status 503;
Context:	http, server, location

设置拒绝请求的返回值。

实战

实例一 限制访问速率

 

limit_req_zone $binary_remote_addr zone=ip_limit:10m rate=10r/s;



server {

  location /login/ {

    limit_req zone=ip_limit;

    proxy_pass http://login_upstream;

  }

}

 

• $binary_remote_addr 针对客户端ip限流；
• zone=ip_limit:10m 限流规则名称为ip_limit，允许使用10MB的内存空间来记录ip对应的限流状态；
• rate=10r/s 限流速度为每秒10次请求
• location /login/ 对登录进行限流 漏桶漏出请求是匀速的。10r/s是怎样匀速的呢？每100ms漏出一个请求。
  在这样的配置下，桶是空的，所有不能实时漏出的请求，都会被拒绝掉。
  所以如果10次请求同时到达，那么只有一个请求能够得到执行，其它的，都会被拒绝。
  这不太友好，大部分业务场景下我们希望这10个请求都能得到执行。

实例二 burst缓存处理 

limit_req_zone $binary_remote_addr zone=ip_limit:10m rate=10r/s;

server {
  location /login/ {
    limit_req zone=ip_limit burst=12;
    proxy_pass http://login_upstream;
  }
}

burst=12 漏桶的大小设置为12

逻辑上叫漏桶，实现起来是FIFO队列，把得不到执行的请求暂时缓存起来。

这样漏出的速度仍然是100ms一个请求，但并发而来，暂时得不到执行的请求，可以先缓存起来。只有当队列满了的时候，才会拒绝接受新请求。

这样漏桶在限流的同时，也起到了削峰填谷的作用。

在这样的配置下，如果有10次请求同时到达，它们会依次执行，每100ms执行1个。

虽然得到执行了，但因为排队执行，延迟大大增加，在很多场景下仍然是不能接受的。

实例三 nodelay降低排队时间

延续实例二的配置，我们加入nodelay选项：

limit_req_zone $binary_remote_addr zone=ip_limit:10m rate=10r/s;

server {
  location /login/ {
    limit_req zone=ip_limit burst=12 nodelay;
    proxy_pass http://login_upstream;
  }
}

 nodelay 把开始执行请求的时间提前，以前是delay到从桶里漏出来才执行，现在不delay了，只要入桶就开始执行。

要么立刻执行，要么被拒绝，请求不会因为限流而增加延迟了。

提高了处理效率，提高了“瞬时处理速度”，平均速度还是受rate限制。当burst满了后不会继续排队等待，直接丢弃。