高并发架构设计，6种常见限流策略，5分钟彻底搞懂

在进行高并发架构设计时，有很多手段来保护系统，如缓存、降级和限流等。

• 通过使用缓存，可以提升系统的访问速度；
• 通过降级策略可以暂时屏蔽非核心业务，保障核心业务不受影响;
• 通过限流对并发访问进行限速，达到一定的速率就可以拒绝服务、排队等待、降级。

欢迎关注笔者，每天分享架构干货。

常见的限流方式有：

1. 限制总并发数（数据库连接池、线程池）
2. 限制瞬时并发数（如Nginx的limit_conn模块）
3. 限制时间窗口的平均速率（如Guava的RateLimiter、Nginx的limit_req模块）
4. 限制远程接口的调用速率
5. 限制MQ的消费速率等

从应用的层面上来讲，又可以分为：接入层限流、应用层限流和分布式限流等。

我们今天主要从两个层面来讲解分布式流控策略，其一：限流算法；其二：应用层限流。

1 限流算法

1.1 令牌桶算法

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

• 假设限制2r/s，则按照500ms的固定速率添加令牌。
• 桶的总容量为N，当达到总容量时，新添加的令牌则被丢弃或拒绝。
• 当一个n个字节大小的数据包到达，则从桶中删除n个令牌，然后处理数据包。
• 如果桶中的令牌不足n个，则不会删除令牌，但是数据包将会被限流。

令牌桶算法（Token Bucket）

1.2 漏桶算法

漏桶可以用于流量整型和流量控制，算法描述如下：

• 一个固定容量的漏桶，会按照固定的速率流出水滴。
• 如果桶中无水，则不需要流出水滴。
• 可以以任意速率流入水滴。
• 如果流入的水滴超出了桶容量，则新添加的则会被丢弃。

漏桶算法

1.3 两种算法对比

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

令牌桶允许一定程度的突发请求（有令牌就可以处理），漏桶的主要目的是来平滑流入的速率。

2 应用级限流

2.1 限制总并发数/连接/请求数

对于一个应用来说，总会有一个TPS/QPS的阀值，如果超过了阀值，则系统就会变得非常慢跟甚至无法响应。因此需要对系统进行过载保护，避免大量请求击垮系统。

如Tomcat的Connector中的以下几个参数：

• acceptCount：如果Tomcat的线程都忙于响应，新来的连接将会进入队列，如果超出队列大小，则会拒绝连接。
• maxConnections：瞬时最大连接数，超出的会排队等待。
• maxThreads：用来处理请求的最大线程数，如果请求处理量一直远远大于线程数，则会引起响应变慢甚至会僵死。

2.2 限制接口的总并发/请求数

在Java中可以用线程安全的AtomicLong或者Semaphore进行处理，如下使用了AtomicLong进行简单的统计：

try {

if (atomic.incrementAndSet() > 阀值) {

// 拒绝请求

}

// 处理请求

} finally {

atomic.decrementAndGet();

}

这种方式实现起来比较简单暴力，没有平滑处理，这需要根据实际情况选择使用。

2.3 限流接口每秒的请求数

限制每秒的请求数，可以使用Guava的Cache来存储计数器，设置过期时间为2s（保证能记录1S内的计数）。下面代码使用当前时间戳的秒数作为key进行统计，这种限流的方式也比较简单。

LoadingCache counter =
 CacheBuilder.newBuilder()
 .expireAfterWrite(2, TimeUnit.SECONDS)
 .build(new CacheLoader() {
 @Override
 public AtomicLong load(Long seconds) 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;
 }
 //业务处理
}

上面介绍的两种限流策略都是单机限流，当系统进行多实例部署时，就无法实现整体对外功能的限流了。如果平行的应用服务器需要共享限流阀值指标，可以使用Redis作为共享的计数器。

2.4平滑限流接口的请求数

Guava的RateLimiter提供的令牌桶算法可以用于平滑突发限流（SmoothBursty）和平滑预热限流（SmoothWarmingUp）实现。

2.5 平滑突发限流

平滑突发限流顾名思义，就是允许突发的流量进入，后面再慢慢的平稳限流。下面给出几个示例：

创建了容量为5的桶，并且每秒新增5个令牌，即每200ms新增一个令牌

RateLimiter limiter = RateLimiter.create(5);
while (true) {
 // 获取令牌，获取后可以执行后续的业务逻辑
 System.out.println(limiter.acquire());
}

上面代码执行结果如下所示：

0.0
0.188216
0.191938
0.199089
0.19724
0.19997

上面while循环中执行的limiter.acquire()，当没有令牌时，此方法会阻塞。实际应用当中应当使用tryAcquire()方法，如果获取不到就直接执行拒绝服务。

下面再介绍一个中途休眠的场景：

RateLimiter limiter = RateLimiter.create(2);
System.out.println(limiter.acquire());
Thread.sleep(1500L);
while (true) {
 System.out.println(limiter.acquire());
}

上面代码执行结果如下：

0.0
0.0
0.0
0.0
0.499794
0.492334

从上面结果可以看出，当线程休眠时，会囤积令牌，留给后续的acquire()使用。但是上面的代码只能囤积1s的令牌（也就是2个），当睡眠时间超过1.5s时，执行结果还是相同的。

2.6 平滑预热限流

平滑突发限流有可能瞬间带来了很大的流量，如果系统扛不住的话，系统很容易挂掉。平滑预热限流可以解决这个问题。方式如下：

permitsPerSecond表示每秒新增的令牌数，warmupPeriod表示从冷启动速率过渡到平均速率所需要的时间间隔：

RateLimiter.create(double permitsPerSecond, long warmupPeriod, TimeUnit unit)
RateLimiter limiter = RateLimiter.create(5, 1000, TimeUnit.MILLISECONDS);
for (int i = 1; i < 5; i++) {
 System.out.println(limiter.acquire());
}
Thread.sleep(1000L);
for (int i = 1; i < 50; i++) {
 System.out.println(limiter.acquire());
}

执行结果如下：

0.0
0.513566
0.353789
0.215167
0.0
0.519854
0.359071
0.219118
0.197874
0.197322
0.197083
0.196838

上面结果可以看出来，平滑预热限流的耗时是慢慢趋近平均值的。

欢迎关注笔者，每天分享架构干货。

参考链接：https://www.jianshu.com/p/5c218b3b5d38