高并发系统限流(一)

介绍

在开发高并发系统时，有很多手段来保护系统，如缓存、降级和限流等。缓存可提升系统访问速度和增大系统处理能力。降级是当系统出问题影响到核心流程业务，可将非核心业务暂时屏蔽掉。限流的目的是通过对并发访问进行限速来保护系统，一旦达到限制速率则可以拒绝服务(定向到错误页或告知资源没有了)、排队或等待(如秒杀、评论和下单)、降级(返回兜底或默认数据，比如商品详情页库存默认有货)。

一般常见限流方式有:

• 限制总并发数，比如数据库连接池，线程池
• 限制瞬时并发数，如Nginx的limit_conn模块
• 限制时间窗口内的平均速率，如Guava的RateLimiter、Nginx的limit_req模块
• 限制远程接口调用速率
• 限制MQ的消费速率

从应用场景来看的话可分为应用级限流、分布式限流、接入层限流。

限流算法

常见的限流算法:令牌桶、漏桶、计数器(粗暴限流)

令牌桶算法

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

• 假设限制2r/s，则按照500ms的固定速率往桶中添加令牌
• 桶中最多存放b个令牌，当桶满时，新添加的令牌被丢弃或拒绝
• 当一个n个字节大小的数据包到达，将从桶中删除n个令牌，接着数据包被发送到网络上
• 如果桶中的令牌不足n个，则不会删除令牌，且该数据包将被限流（要么丢弃，要么在缓冲区等待）

漏桶算法

漏桶作为计量工具时，可以用于流量整形和流量控制，算法描述如下：

• 一个固定容量的漏桶，按照常量固定速率流出水滴
• 如果桶是空的则不需流出水滴
• 可以以任意速率流入水滴到漏桶
• 如果流入水滴超出了桶的容量，则流出的水滴溢出了（被丢弃），而漏桶容量是不变的

计数器

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

上面就是基本的限流算法，其中令牌桶和漏桶主要区别为:

1. 令牌桶按照固定速率往桶中添加令牌，漏桶则是按照常量固定速率流出请求。
2. 令牌桶允许一定程度的突发(只要有令牌就可以处理)，漏桶的主要目的是平滑流入速率。

应用级限流

限流总并发/连接/请求数

对于一个应用系统来说，总有一个TPS/QPS阈值，如果超过了阈值，则系统就会不响应用户请求或响应的非常慢，因此我们最好进行过载保护，以防止大量请求涌入击垮系统。

如Tomcat中的Connector其中一种配置有如下参数：

acceptCount：如果Tomcat线程都忙于响应，新来的连接会进入队列排队，如果超出排队大小，则拒绝连接

maxConnections：瞬时最大连接数，超出的会排队等待

maxThreads：Tomcat能启动用来处理请求的最大线程数，如果请求处理数一直远远大于最大线程数，则会引起响应变慢甚至会僵死。

另外如MySQL、Redis都会有类似的限制连接数的配置。

限流总资源数

可以使用池化技术来限制总资源数，如连接池和线程池，超出可以等待或者抛异常

限流接口的总并发/请求数

接口可能会有突发访问情况，可能会由于访问量过大造成崩溃，这个时候就需要限制接口的总并发或者请求数。

可以使用Java中的AtomicLong或Semaphore进行限流。

try {
    //limit为限流数
    if(atomic.incrementAndGet() > limit){
        //拒绝请求
    }
    //处理请求
} finally {
    atomic.decrementAndGet();
}
复制代码

适合可降级业务或者需要过载保护的服务进行限流，如抢购业务（超出排队或者直接通知没货）。一些开放平台限制用户调用某个接口的试用请求量也可使用此种方式。这种限流方式比较简单暴力，没有平滑处理，需要根据实际情况选择使用。

限流接口时间窗请求数

如果想限制接口每秒/每分钟/每天等时间段内的请求数，就需要对请求数进行限速。可以使用Guava的Cache来存储计数器，过期时间设置为2s(保证记录1s内的计数)。获取当前时间戳取秒数来作为key进行计数统计和限流。

LoadingCache<Long, AtomicLong> counter =
        CacheBuilder.newBuilder()
                .expireAfterWrite(2, TimeUnit.SECONDS)
                .build(new CacheLoader<Long, AtomicLong>() {
                    @Override
                    public AtomicLong load(Long key) throws Exception {
                        return new AtomicLong(0);
                    }
                });
long limit = 1000;
while (true) {
    //得到当前秒
    long currentSeconds = System.currentTimeMillis() / 1000;
    if(counter.get(currentSeconds).incrementAndGet() > limit){
        System.out.println("限流了:" + currentSeconds);
        continue;
    }
    //业务处理
}
复制代码

这种方式也是简单粗暴没有平滑处理，但是应对每秒或每分钟的大请求量等场景已经够用了。如一些基础服务会被很多其它系统调用，请求辆过大就需要对每秒/分钟调用量进行限速。

平滑限流接口的请求数

上面所说的限流方式瞬间请求可能被允许从而导致一些问题。则在一些场景需要对突发请求整形为平均速率请求处理。我们会想到前面我们介绍的令牌桶和漏桶算法满足咱们的要求。

Guava RateLimiter提供的令牌桶算法 可以用于平滑突发限流(SmoothBursty)和平滑预热限流(Smooth WarmingUp)实现。

平滑突发限流(SmoothBursty)

允许突发请求，后面的请求会整形为固定速率。

//表示桶容量为5且每秒新增5个令牌(每隔200ms新增一个令牌)
RateLimiter limiter = RateLimiter.create(5);
//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());
System.out.println(limiter.acquire());
复制代码

执行结果如下：

0.0
0.194412
0.196526
0.19883
0.197466
0.19534
复制代码

上面的第一次直接获得令牌，后面的大概都要等待200ms获取令牌。执行结果可以看出为固定请求速率。上面的limiter.acquire()为每次获取一个令牌，当然我们也可以一次性获取多个令牌。例如一次性获取五个可以用limiter.acquire(5)。

/**
 * Acquires permits from this {@link RateLimiter} if it can be acquired immediately without delay.
 *
 * <p>This method is equivalent to {@code tryAcquire(permits, 0, anyUnit)}.
 *
 * @param permits the number of permits to acquire
 * @return {@code true} if the permits were acquired, {@code false} otherwise
 * @throws IllegalArgumentException if the requested number of permits is negative or zero
 * @since 14.0
 */
public boolean tryAcquire(int permits) {
  return tryAcquire(permits, 0, MICROSECONDS);
}
复制代码

我们再来看中途休眠突发的例子:

RateLimiter limiter = RateLimiter.create(2);
System.out.println(limiter.acquire());
Thread.sleep(2000L);
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());
复制代码

执行结果为：

0.0
0.0
0.0
0.0
0.499609
0.491548
复制代码

可见线程休眠时会生成令牌在桶中囤积，桶容量为2，则最多囤积1s的令牌2个。暂存的令牌允许未来请求的突发。

有人可能对RateLimiter.create(2)表示的意思有点困惑，这里的参数2代表的是每秒可用的许可数，但是桶的容量为什么也是2？那是因为SmoothBursty有一个最大突发秒数（maxBurstSeconds）的参数，桶容量=速率最大突发秒数(permitsPerSecondmaxBurstSeconds),maxBurstSeconds这个参数默认为1，则RateLimiter.create(2)的桶容量为2.

static RateLimiter create(double permitsPerSecond, SleepingStopwatch stopwatch) {
  RateLimiter rateLimiter = new SmoothBursty(stopwatch, 1.0 /* maxBurstSeconds */);
  rateLimiter.setRate(permitsPerSecond);
  return rateLimiter;
}
复制代码

SmoothBursty通过平均速率和最后一次新增令牌的时间计算出下一次新增令牌的时间。另外需要一个桶暂存一段时间内没有使用的令牌（可以突发的令牌数）。RateLimiter还提供了tryAcquire()方法来进行无阻塞或可超时的令牌消费。

/**
 * Acquires a permit from this {@link RateLimiter} if it can be acquired immediately without
 * delay.
 *
 * <p>This method is equivalent to {@code tryAcquire(1)}.
 *
 * @return {@code true} if the permit was acquired, {@code false} otherwise
 * @since 14.0
 */
public boolean tryAcquire() {
  return tryAcquire(1, 0, MICROSECONDS);
}

/**
 * Acquires a permit from this {@code RateLimiter} if it can be obtained without exceeding the
 * specified {@code timeout}, or returns {@code false} immediately (without waiting) if the permit
 * would not have been granted before the timeout expired.
 *
 * <p>This method is equivalent to {@code tryAcquire(1, timeout, unit)}.
 *
 * @param timeout the maximum time to wait for the permit. Negative values are treated as zero.
 * @param unit the time unit of the timeout argument
 * @return {@code true} if the permit was acquired, {@code false} otherwise
 * @throws IllegalArgumentException if the requested number of permits is negative or zero
 */
public boolean tryAcquire(long timeout, TimeUnit unit) {
  return tryAcquire(1, timeout, unit);
}
复制代码

SmoothBurst允许一定程度的突发，但这种突发量很大的话，那么系统也是有可能扛不住的。所以需要一种平滑速率的限流工具，在系统冷启动后慢慢趋于平均固定速率（即刚开始速率小一些，慢慢趋于设置的固定速率）。RateLimiter提供了SmoothWarmingUp来实现这种需求。

平滑预热限流(Smooth WarmingUp)

创建方式RateLimiter.create(double permitsPerSecond, long warmupPeriod, TimeUnit unit)：

//permitsPerSecond:表示每秒新增的令牌数
//warmupPeriod:表示从冷启动速率过渡到平均速率的时间间隔
public static RateLimiter create(double permitsPerSecond, long warmupPeriod, TimeUnit unit) {
  checkArgument(warmupPeriod >= 0, "warmupPeriod must not be negative: %s", warmupPeriod);
  return create(
      permitsPerSecond, warmupPeriod, unit, 3.0, SleepingStopwatch.createFromSystemTimer());
}
复制代码

我们来看个示例：

RateLimiter limiter = RateLimiter.create(5, 1000, TimeUnit.MILLISECONDS);
for (int i = 0; i < 5; i++){
    System.out.println(limiter.acquire());
}
Thread.sleep(1000L);
for (int i = 0; i < 5; i++){
    System.out.println(limiter.acquire());
}
复制代码

执行结果如下：

0.0
0.516492
0.354163
0.219246
0.195781
0.0
0.366611
0.222908
0.196205
0.196275
复制代码

从执行结果来看是从一个比较大的速率慢慢的趋于平均速率。应用级限流我们就讲到这。

总结

本文主要介绍了限流的算法以及应用级层次的限流。但如果应用部署到多台机器上，应用级限流只能单应用内请求限流，不能全局限流。如果要解决全局限流的问题，就需要分布式限流和接入层限流。

参考书籍:《亿级流量网站架构核心技术》