限流（Rate limit）算法详解

分手后的思念是犯贱 2022-09-11 01:15 160阅读 0赞

一、前言  
保障服务稳定的三大利器：熔断降级、服务限流和故障模拟。今天和大家谈谈限流算法的几种实现方式，本文所说的限流并非是Nginx层面的限流，而是业务代码中的逻辑限流。

那么为什么需要限流呢？  
按照服务的调用方，可以分为以下几种类型服务

1、与用户打交道的服务  
比如web服务、对外API，这种类型的服务有以下几种可能导致机器被拖垮：

用户增长过快（这是好事）  
因为某个热点事件（微博热搜）  
竞争对象爬虫  
恶意的刷单  
这些情况都是无法预知的，不知道什么时候会有10倍甚至20倍的流量打进来，如果真碰上这种情况，扩容是根本来不及的（弹性扩容都是虚谈，一秒钟你给我扩一下试试）。

2、对内的RPC服务  
一个服务A的接口可能被BCDE多个服务进行调用，在B服务发生突发流量时，直接把A服务给调用挂了，导致A服务对CDE也无法提供服务。 这种情况时有发生，解决方案有两种：

每个调用方采用线程池进行资源隔离  
使用限流手段对每个调用方进行限流  
二、限流算法简介  
限流即流量限制，也叫做流量整形。限流的目的是在遇到流量高峰期或者流量突增（流量尖刺）时，通过对流量速率进行限制，当达到限制速率时，可以拒绝服务（定向到错误页或告知资源没有了）、排队或等待（比如秒杀、评论、下单）、降级（返回兜底数据或默认数据，如商品详情页库存默认有货）。以把流量控制在系统所能接受的合理范围之内，不至于让系统被高流量击垮。

三、常见限流算法  
常用的限流算法大致有三种：漏桶算法、令牌桶算法、计数器算法

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

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

2.令牌桶算法  
从某种意义上讲，令牌桶算法是对漏桶算法的一种改进，桶算法能够限制请求调用的速率，而令牌桶算法能够在限制调用的平均速率的同时还允许一定程度的突发调用。

在令牌桶算法中，存在一个桶，用来存放固定数量的令牌。算法中存在一种机制，以一定的速率往桶中放令牌。每次请求调用需要先获取令牌，只有拿到令牌，才有机会继续执行，否则选择选择等待可用的令牌、或者直接拒绝。

放令牌这个动作是持续不断的进行，如果桶中令牌数达到上限，就丢弃令牌，所以就存在这种情况，桶中一直有大量的可用令牌，这时进来的请求就可以直接拿到令牌执行，比如设置qps为100，那么限流器初始化完成一秒后，桶中就已经有100个令牌了，这时服务还没完全启动好，等启动完成对外提供服务时，该限流器可以抵挡瞬时的100个请求。所以，只有桶中没有令牌时，请求才会进行等待，最后相当于以一定的速率执行。

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

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

3.令牌桶和漏桶对比：  
令牌桶是按照固定速率往桶中添加令牌，请求是否被处理需要看桶中令牌是否足够，当令牌数减为零时则拒绝新的请求；  
漏桶则是按照常量固定速率流出请求，流入请求速率任意，当流入的请求数累积到漏桶容量时，则新流入的请求被拒绝；  
令牌桶限制的是平均流入速率（允许突发请求，只要有令牌就可以处理，支持一次拿3个令牌，4个令牌），并允许一定程度突发流量；  
漏桶限制的是常量流出速率（即流出速率是一个固定常量值，比如都是1的速率流出，而不能一次是1，下次又是2），从而平滑突发流入速率；  
令牌桶允许一定程度的突发，而漏桶主要目的是平滑流入速率；  
两个算法实现可以一样，但是方向是相反的，对于相同的参数得到的限流效果是一样的  
4.计数器算法  
使用计数器来进行限流，主要用来限制总并发数（集群限流），比如数据库连接池、线程池、秒杀的并发数；只要全局总请求数或者一定时间段的总请求数设定的阀值则进行限流，是简单粗暴的总数量限流，而不是平均速率限流。

计数器算法是限流算法里最简单也是最容易实现的一种算法。比如我们规定，对于A接口来说，我们1分钟的访问次数不能超过100个。那么我们可以这么做：在一开 始的时候，我们可以设置一个计数器counter，每当一个请求过来的时候，counter就加1，如果counter的值大于100并且该请求与第一个 请求的间隔时间还在1分钟之内，那么说明请求数过多；如果该请求与第一个请求的间隔时间大于1分钟，且counter的值还在限流范围内，那么就重置 counter。

这种算法虽然简单，但有很致命的问题，用户通过在时间窗口的重置节点处突发请求，可以瞬间超过我们的速率限制，然后压垮我们的应用。

5.滑动窗口算法  
刚才的问题其实是因为我们统计的精度太低。那么如何很好地处理这个问题呢？

滑动窗口，又称rolling window。

在上图中，整个红色的矩形框表示一个时间窗口，在我们的例子中，一个时间窗口就是一分钟。然后我们将时间窗口进行划分，比如图中，我们就将滑动窗口 划成了6格，所以每格代表的是10秒钟。每过10秒钟，我们的时间窗口就会往右滑动一格。每一个格子都有自己独立的计数器counter，比如当一个请求 在0:35秒的时候到达，那么0:30~0:39对应的counter就会加1。

那么滑动窗口怎么解决刚才的临界问题的呢？我们可以看上图，0:59到达的100个请求会落在灰色的格子中，而1:00到达的请求会落在橘黄色的格 子中。当时间到达1:00时，我们的窗口会往右移动一格，那么此时时间窗口内的总请求数量一共是200个，超过了限定的100个，所以此时能够检测出来触 发了限流。

我再来回顾一下刚才的计数器算法，我们可以发现，计数器算法其实就是滑动窗口算法。只是它没有对时间窗口做进一步地划分，所以只有1格。

由此可见，当滑动窗口的格子划分的越多，那么滑动窗口的滚动就越平滑，限流的统计就会越精确。

四、限流算法代码  
1.漏桶算法实现的伪代码  
long timeStamp=getNowTime();  
int capacity;  // 桶的容量  
int rate ;     // 水漏出的速度  
int water;     // 当前水量  
   
bool grant() \{  
  //先执行漏水，因为rate是固定的，所以可以认为“时间间隔\*rate”即为漏出的水量  
  long now = getNowTime();  
  water = max(0, water- (now - timeStamp)\*rate);  
  timeStamp = now;  
   
  if water < capacity \{ // 水还未满，加水  
    water ++;  
    return true;  
  \} else \{  
    return false;//水满，拒绝加水  
  \}  
\}  
2.令牌桶算法代码演示  
Guava是google提供的java扩展类库，其中的限流工具类RateLimiter采用的就是令牌桶算法。RateLimiter 从概念上来讲，速率限制器会在可配置的速率下分配许可证，如果必要的话，每个acquire() 会阻塞当前线程直到许可证可用后获取该许可证，一旦获取到许可证，不需要再释放许可证。通俗的讲RateLimiter会按照一定的频率往桶里扔令牌，线程拿到令牌才能执行，比如你希望自己的应用程序QPS不要超过1000，那么RateLimiter设置1000的速率后，就会每秒往桶里扔1000个令牌。例如我们需要处理一个任务列表，但我们不希望每秒的任务提交超过两个，此时可以采用如下方式：

public class RateLimiterDemo \{  
    private static RateLimiter limiter = RateLimiter.create(5);  
   
    public static void exec() \{  
        limiter.acquire(1);  
        try \{  
            // 处理核心逻辑  
            TimeUnit.SECONDS.sleep(1);  
            System.out.println("--" + System.currentTimeMillis() / 1000);  
        \} catch (InterruptedException e) \{  
            e.printStackTrace();  
        \}  
    \}  
\}  
有一点很重要，那就是请求的许可数从来不会影响到请求本身的限制（调用acquire(1) 和调用acquire(1000) 将得到相同的限制效果，如果存在这样的调用的话），但会影响下一次请求的限制，也就是说，如果一个高开销的任务抵达一个空闲的RateLimiter，它会被马上许可，但是下一个请求会经历额外的限制，从而来偿付高开销任务。注意：RateLimiter 并不提供公平性的保证。 五、Hystrix中的限流算法

3.计数器限流示例1  
public class CountRateLimiterDemo1 \{  
    private static AtomicInteger count = new AtomicInteger(0);  
    public static void exec() \{  
        if (count.get() >= 5) \{  
            System.out.println("请求用户过多，请稍后在试！"+System.currentTimeMillis()/1000);  
        \} else \{  
            count.incrementAndGet();  
            try \{  
                //处理核心逻辑  
                TimeUnit.SECONDS.sleep(1);  
                System.out.println("--"+System.currentTimeMillis()/1000);  
            \} catch (InterruptedException e) \{  
                e.printStackTrace();  
            \} finally \{  
                count.decrementAndGet();  
            \}  
        \}  
    \}  
\}  
使用AomicInteger来进行统计当前正在并发执行的次数，如果超过域值就简单粗暴的直接响应给用户，说明系统繁忙，请稍后再试或其它跟业务相关的信息。   
弊端：使用 AomicInteger 简单粗暴超过域值就拒绝请求，可能只是瞬时的请求量高，也会拒绝请求。

4.计数器限流示例2  
public class CountRateLimiterDemo2 \{  
   
    private static Semaphore semphore = new Semaphore(5);  
   
    public static void exec() \{  
        if(semphore.getQueueLength()>100)\{  
            System.out.println("当前等待排队的任务数大于100，请稍候再试...");  
        \}  
        try \{  
            semphore.acquire();  
            // 处理核心逻辑  
            TimeUnit.SECONDS.sleep(1);  
            System.out.println("--" + System.currentTimeMillis() / 1000);  
        \} catch (InterruptedException e) \{  
            e.printStackTrace();  
        \} finally \{  
            semphore.release();  
        \}  
    \}  
\}  
使用Semaphore信号量来控制并发执行的次数，如果超过域值信号量，则进入阻塞队列中排队等待获取信号量进行执行。如果阻塞队列中排队的请求过多超出系统处理能力，则可以在拒绝请求。

相对Atomic优点：如果是瞬时的高并发，可以使请求在阻塞队列中排队，而不是马上拒绝请求，从而达到一个流量削峰的目的。  
————————————————  
  
原文链接：https://blog.csdn.net/fuqianming/article/details/100532819