分布式系统限流策略（一）

原创 分布式系统 共4631人围观 0个不明物体

在开发高并发的系统时，有很多手段来保护系统，如缓存、降级和限流等。缓存可以提升系统的访问速度，降级可以暂时屏蔽掉非核心业务，使得核心业务不受影响。限流的目的通过对并发访问进行限速，一旦达到一定的速率就可以拒绝服务（定向到错误页或告知资源没有了）、排队等待（如秒杀、评论、下单等）、降级（直接返回兜底数据、如商品库存默认有货）。

常见的限流方式有：限制总并发数（数据库连接池、线程池）、限制瞬时并发数（如Nginx的limit_conn模块）、限制时间窗口的平均速率（如Guava的RateLimiter、Nginx的limit_req模块）、限制远程接口的调用速率、限制MQ的消费速率等。从应用的层面上来讲，又可以分为：接入层限流、应用层限流和分布式限流等。

限流算法

令牌桶算法

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

1、假设限制2r/s，则按照500ms的固定速率添加令牌。

2、桶的总容量为N，当达到总容量时，新添加的令牌则被丢弃或拒绝。

3、当一个n个字节大小的数据包到达，则从桶中删除n个令牌，然后处理数据包。

4、如果桶中的令牌不足n个，则不会删除令牌，但是数据包将会被限流。

漏桶算法

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

1、一个固定容量的漏桶，会按照固定的速率流出水滴。

2、如果桶中无水，则不需要流出水滴。

3、可以以任意速率流入水滴。

4、如果流入的水滴超出了桶容量，则新添加的则会被丢弃。

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

应用级限流

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

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

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

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

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

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

类似于Tomcat配置最大连接数等参数，Redis和MySQL也有相关的配置。

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

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

try {
    if (atomic.incrementAndSet() > 阀值) {
        // 拒绝请求
    }
    // 处理请求
} 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 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;
    }
    //业务处理
}

上面介绍的2中限流方案都是对于单机接口的限流，当系统进行多机部署时，就无法实现整体对外功能的限流了。当然这也看具体的应用场景，如果平行的应用服务器需要共享限流阀值指标，可以使用Redis作为共享的计数器。

平滑限流接口的请求数

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

平滑突发限流（SmoothBursty）

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

# 创建了容量为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时，执行结果还是相同的。

平滑预热限流（SmoothWarmingUp）

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

// 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

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


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

标签：

相关推荐