限流方案

程序开发时，系统在短时间内访问量暴增，会导致程序崩溃，这个时候我们需要使用限流，下面对get到的限流方案整理如下：

1. 合法性验证限流：比如验证码、IP 黑名单等，这些手段可以有效的防止恶意攻击和爬虫采集；
2. 容器限流：比如 Tomcat、Nginx 等限流手段，其中 Tomcat 可以设置最大线程数（maxThreads），当并发超过最大线程数会排队等待执行；而 Nginx 提供了两种限流手段：一是控制速率，二是控制并发连接数；
3. 服务端限流：比如我们在服务器端通过限流算法实现限流；

合法性验证限流：为最常规的业务代码，就是普通的验证码，配置 IP 黑名单、白名单；

容器限流：

一、tomcat限流：在conf/server.xml文件中配置tomcat8.5版本的maxThreads最多线程数，达到限流的目的。注意maxThreads也不是越大越好，要看具体的硬件配置，需要注意的是每开启一个线程需要耗用 1MB 的 JVM 内存空间用于作为线程栈之用，并且线程越多 GC 的负担也越重。最后需要注意一下，操作系统对于进程中的线程数有一定的限制，Windows 每个进程中的线程数不允许超过 2000，Linux 每个进程中的线程数不允许超过 1000。具体配置如下：

<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" maxThreads="150" redirectPort="8443" />

二、nginx限流：nginx提供两种限流的手段，一是控制速率(漏桶算法实现的)、二是控制并发连接数。

1. 限制每个ip访问的速度为2r/s，即500ms内单个ip只允许通过一个请求；比如单个ip在10ms 内发并发送了 6 个请求，只有 1 个执行成功了，其他的 5 个被拒绝了（第 2 个在 501ms 才会被正常执行）。配置如下：

   limit_req_zone $binary_remote_addr zone=mylimit:10m rate=2r/s;
   server { 
       location / { 
           limit_req zone=mylimit;
       }
   }

    

2. 使用burst关键字控制一个ip单位总时间内的总访问次数，burst=4 表示每个 IP 最多允许4个突发请求，如果单个 IP 在 10ms 内发送 6 次请求，有 1 个请求被立即处理了，4 个请求被放到 burst 队列里排队执行了，另外 1 个请求被拒绝了。配置如下：

   limit_req_zone $binary_remote_addr zone=mylimit:10m rate=2r/s;
   server { 
       location / { 
           limit_req zone=mylimit burst=4;
       }
   }

    

3. 利用 limit_conn_zone 和 limit_conn 两个指令即可控制并发数，其中 limit_conn perip 10 表示限制单个 IP 同时最多能持有 10 个连接；limit_conn perserver 100 表示 server 同时能处理并发连接的总数为 100 个。只有当 request header 被后端处理后，这个连接才进行计数。配置如下：

   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;
   }

    

服务端限流：

一、时间窗口算法：借助 Redis 的有序集合 ZSet 来实现时间窗口算法限流，实现的过程是先使用 ZSet 的 key 存储限流的 ID，score 用来存储请求的时间，每次有请求访问来了之后，先清空之前时间窗口的访问量，统计现在时间窗口的个数和最大允许访问量对比，如果大于等于最大访问量则返回 false 执行限流操作，负责允许执行业务逻辑，并且在 ZSet 中添加一条有效的访问记录。

<!-- https://mvnrepository.com/artifact/redis.clients/jedis -->
<dependency>
    <groupId>redis.clients</groupId>
    <artifactId>jedis</artifactId>
    <version>3.3.0</version>
</dependency>

import redis.clients.jedis.Jedis;

public class RedisLimit {
    // Redis 操作客户端
    static Jedis jedis = new Jedis("127.0.0.1", 6379);

    public static void main(String[] args) throws InterruptedException {
        for (int i = 0; i < 15; i++) {
            boolean res = isPeriodLimiting("java", 3, 10);
            if (res) {
                System.out.println("正常执行请求：" + i);
            } else {
                System.out.println("被限流：" + i);
            }
        }
        // 休眠 4s
        Thread.sleep(4000);
        // 超过最大执行时间之后，再从发起请求
        boolean res = isPeriodLimiting("java", 3, 10);
        if (res) {
            System.out.println("休眠后，正常执行请求");
        } else {
            System.out.println("休眠后，被限流");
        }
    }

    /**
     * 限流方法（滑动时间算法）
     * @param key      限流标识
     * @param period   限流时间范围（单位：秒）
     * @param maxCount 最大运行访问次数
     * @return
     */
    private static boolean isPeriodLimiting(String key, int period, int maxCount) {
        long nowTs = System.currentTimeMillis(); // 当前时间戳
        // 删除非时间段内的请求数据（清除老访问数据，比如 period=60 时，标识清除 60s 以前的请求记录）
        jedis.zremrangeByScore(key, 0, nowTs - period * 1000);
        long currCount = jedis.zcard(key); // 当前请求次数
        if (currCount >= maxCount) {
            // 超过最大请求次数，执行限流
            return false;
        }
        // 未达到最大请求数，正常执行业务
        jedis.zadd(key, nowTs, "" + nowTs); // 请求记录 +1
        return true;
    }
}

执行结果：
正常执行请求：0
正常执行请求：1
正常执行请求：2
正常执行请求：3
正常执行请求：4
正常执行请求：5
正常执行请求：6
正常执行请求：7
正常执行请求：8
正常执行请求：9
被限流：10
被限流：11
被限流：12
被限流：13
被限流：14
休眠后，正常执行请求

此实现方式存在两个缺点：

• 使用 ZSet 存储有每次的访问记录，如果数据量比较大时会占用大量的空间，比如 60s 允许 100W 访问时；
• 此代码的执行非原子操作，先判断后增加，中间空隙可穿插其他业务逻辑的执行，最终导致结果不准确。

二、漏桶算法：先声明一个队列用来保存请求，这个队列相当于漏斗，当队列容量满了之后就放弃新来的请求，然后重新声明一个线程定期从任务队列中获取一个或多个任务进行执行，我们可以使用Redis4.0版本中的Redis-Cell 模块提供的原子限流指令，实现限流，示例如下：

> cl.throttle mylimit 15 30 60
1）（integer）0 # 0 表示获取成功，1 表示拒绝
2）（integer）15 # 漏斗容量
3）（integer）14 # 漏斗剩余容量
4）（integer）-1 # 被拒绝之后，多长时间之后再试（单位：秒）-1 表示无需重试
5）（integer）2 # 多久之后漏斗完全空出来

其中 15 为漏斗的容量，30 / 60s 为漏斗的速率。

三、令牌算法：一个程序以某种恒定的速度生成令牌，并存入令牌桶中，而每个请求需要先获取令牌才能执行，如果没有获取到令牌的请求可以选择等待或者放弃执行，我们可以使用 Google 开源的 guava 包，很方便的实现令牌桶算法(使用 guava 实现的令牌算法属于程序级别的单机限流方案)，示例如下：

<!-- https://mvnrepository.com/artifact/com.google.guava/guava -->
<dependency>
    <groupId>com.google.guava</groupId>
    <artifactId>guava</artifactId>
    <version>28.2-jre</version>
</dependency>

import com.google.common.util.concurrent.RateLimiter;

import java.time.Instant;

/**
 * Guava 实现限流
 */
public class RateLimiterExample {
    public static void main(String[] args) {
        // 每秒产生 10 个令牌（每 100 ms 产生一个）
        RateLimiter rt = RateLimiter.create(10);
        for (int i = 0; i < 11; i++) {
            new Thread(() -> {
                // 获取 1 个令牌
                rt.acquire();
                System.out.println("正常执行方法，ts:" + Instant.now());
            }).start();
        }
    }
}

执行结果：
正常执行方法，ts:2020-05-15T14:46:37.175Z
正常执行方法，ts:2020-05-15T14:46:37.237Z
正常执行方法，ts:2020-05-15T14:46:37.339Z
正常执行方法，ts:2020-05-15T14:46:37.442Z
正常执行方法，ts:2020-05-15T14:46:37.542Z
正常执行方法，ts:2020-05-15T14:46:37.640Z
正常执行方法，ts:2020-05-15T14:46:37.741Z
正常执行方法，ts:2020-05-15T14:46:37.840Z
正常执行方法，ts:2020-05-15T14:46:37.942Z
正常执行方法，ts:2020-05-15T14:46:38.042Z
正常执行方法，ts:2020-05-15T14:46:38.142Z

从以上结果可以看出令牌确实是每 100ms 产生一个，而 acquire() 方法为阻塞等待获取令牌，它可以传递一个 int 类型的参数，用于指定获取令牌的个数。它的替代方法还有 tryAcquire()，此方法在没有可用令牌时就会返回 false 这样就不会阻塞等待了。当然 tryAcquire() 方法也可以设置超时时间，未超过最大等待时间会阻塞等待获取令牌，如果超过了最大等待时间，还没有可用的令牌就会返回 false。