转载

Guava平滑限流

1.常用限流方法

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

常见的限流方法有:

容器限流

常见的web容器其实也具备限流的功能。

以Tomcat容器为例,其Connector 其中一种配置有如下几个参数:

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

maxConnections: 瞬时最大连接数,超出的会排队等待;

maxThreads:Tomcat能启动用来处理请求的最大线程数,如果请求处理量一直远远大于最大线程数则可能会僵死。

限流总资源数

如果有的资源是稀缺资源(如数据库连接、线程),而且可能有多个系统都会去使用它,那么需要限制应用;可以使用池化技术来限制总资源数:连接池、线程池。比如分配给每个应用的数据库连接是100,那么本应用最多可以使用100个资源,超出了可以等待或者抛异常。

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

如果接口可能会有突发访问情况,但又担心访问量太大造成崩溃,如抢购业务;这个时候就需要限制这个接口的总并发请求数了;因为粒度比较细,可以为每个接口都设置相应的阀值。可以使用Java中的AtomicLong进行限流:

try {

if(atomic.incrementAndGet() > 限流数) {

//拒绝请求

}

//处理请求

} finally {

atomic.decrementAndGet();

}

利用Netflix的hystrix限流

2.漏桶算法 VS 令牌桶算法

2.1 漏桶算法(Leaky Bucket)

漏桶算法(Leaky Bucket):水(请求)先进入到漏桶里,漏桶以一定的速度出水(接口有响应速率),当水流入速度过大会直接溢出(访问频率超过接口响应速率),然后就拒绝请求,可以看出漏桶算法能强行限制数据的传输速率.示意图如下:

Guava平滑限流

Guava平滑限流

可见这里有两个变量,一个是桶的大小,支持流量突发增多时可以存多少的水(burst),另一个是水桶漏洞的大小(rate)。

2.2 令牌桶算法(Token Bucket)

令牌桶算法(Token Bucket)和 Leaky Bucket 效果一样但方向相反的算法,更加容易理解.随着时间流逝,系统会按恒定1/QPS时间间隔(如果QPS=100,则间隔是10ms)往桶里加入Token(想象和漏洞漏水相反,有个水龙头在不断的加水),如果桶已经满了就不再加了.新请求来临时,会各自拿走一个Token,如果没有Token可拿了就阻塞或者拒绝服务.

Guava平滑限流

Guava平滑限流

令牌桶的另外一个好处是可以方便的改变速度. 一旦需要提高速率,则按需提高放入桶中的令牌的速率. 一般会定时(比如100毫秒)往桶中增加一定数量的令牌, 有些变种算法则实时的计算应该增加的令牌的数量.

2.3 漏桶算法VS令牌桶算法

令牌桶是按照固定速率往桶中添加令牌,请求是否被处理需要看桶中令牌是否足够,当令牌数减为零时则拒绝新的请求;

漏桶则是按照常量固定速率流出请求,流入请求速率任意,当流入的请求数累积到漏桶容量时,则新流入的请求被拒绝;

令牌桶限制的是平均流入速率(允许突发请求,只要有令牌就可以处理,支持一次拿3个令牌,4个令牌),并允许一定程度突发流量;

漏桶限制的是常量流出速率(即流出速率是一个固定常量值,比如都是1的速率流出,而不能一次是1,下次又是2),从而平滑突发流入速率;

令牌桶允许一定程度的突发,而漏桶主要目的是平滑流入速率;

两个算法实现可以一样,但是方向是相反的,对于相同的参数得到的限流效果是一样的。

3.Guava实现平滑限流

3.1Guava是什么

Guava是一个开源的Java库,其中包含谷歌很多项目使用的核心库。这个库是为了方便编码,并减少编码错误。这个库提供用于集合,缓存,支持原语,并发性,常见注解,字符串处理,I/O和验证的实用方法。

3.2Guava RateLimiter实现平滑限流

Guava RateLimiter提供了令牌桶算法实现:平滑突发限流(SmoothBursty)和平滑预热限流(SmoothWarmingUp)实现。

平滑突发限流:

/**

* 平滑突发限流(SmoothBursty)

*/

public class SmoothBurstyRateLimitTest {

public static void main(String[] args) {

//QPS = 5,每秒允许5个请求

RateLimiter limiter = RateLimiter.create(5);

//limiter.acquire() 返回获取token的耗时,以秒为单位

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.19667

0.195784

0.194672

0.195658

0.195285

/**

* 平滑突发限流(smoothbursty)

*/

public class SmoothBurstyRateLimitTest02 {

public static void main(String[] args) {

//每秒允许5个请求,表示桶容量为5且每秒新增5个令牌,即每隔0.2毫秒新增一个令牌

RateLimiter limiter = RateLimiter.create(5);

//一次性消费5个令牌

System.out.println(limiter.acquire(5));

//limiter.acquire(1)将等待差不多1秒桶中才能有令牌

System.out.println(limiter.acquire(1));

//固定速率

System.out.println(limiter.acquire(1));

//固定速率

System.out.println(limiter.acquire(1));

//固定速率

System.out.println(limiter.acquire(1));

}

}

/**

* 平滑突发限流(smoothbursty)

*/

public class SmoothBurstyRateLimitTest03 {

public static void main(String[] args) {

//每秒允许5个请求,表示桶容量为5且每秒新增5个令牌,即每隔0.2毫秒新增一个令牌

RateLimiter limiter = RateLimiter.create(5);

//第一秒突发了10个请求

System.out.println(limiter.acquire(10));

//limiter.acquire(1)将等待差不多2秒桶中才能有令牌

System.out.println(limiter.acquire(1));

//固定速率

System.out.println(limiter.acquire(1));

//固定速率

System.out.println(limiter.acquire(1));

//固定速率

System.out.println(limiter.acquire(1));

}

}

平滑预热限流:

/**

* 平滑预热限流(SmoothWarmingUp)

*/

public class SmoothWarmingUp {

public static void main(String[] args) {

//permitsPerSecond:每秒新增的令牌数 warmupPeriod:从冷启动速率过渡到平均速率的时间间隔

//系统冷启动后慢慢的趋于平均固定速率(即刚开始速率慢一些,然后慢慢趋于我们设置的固定速率)

RateLimiter limiter = RateLimiter.create(10, 1000, TimeUnit.MILLISECONDS);

for(int i = 0; i < 10;i++) {

//获取一个令牌

System.out.println(limiter.acquire(1));

}

}

}

秒杀场景:

/**

* 秒杀场景模拟

*/

public class MiaoShaTest {

public static void main(String[] args) throws InterruptedException {

//限流,每秒允许10个请求进入秒杀

RateLimiter limiter = RateLimiter.create(10);

for (int i = 0; i < 100; i++) {

//100个线程同时抢购

new Thread(() -> {

//每个秒杀请求如果100ms以内得到令牌,就算是秒杀成功,否则就返回秒杀失败

if (limiter.tryAcquire(50, TimeUnit.MILLISECONDS)) {

System.out.println(“恭喜您,秒杀成功”);

} else {

System.out.println(“秒杀失败,请继续努力”);

}

}).start();

//等待新的令牌生成

Thread.sleep(10);

}

}

}

测试demo地址:https://github.com/online-demo/yunxi-guava

————————————————

版权声明:本文为CSDN博主「ShiXueTanLang」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。

原文链接:https://blog.csdn.net/ShiXueTanLang/article/details/80960208

—————-

三种常见的限流算法

在开发高并发系统时,有三把利器用来保护系统:缓存、降级和限流。那么何为限流呢?顾名思义,限流就是限制流量,就像你宽带包了1个G的流量,用完了就没了。通过限流,我们可以很好地控制系统的qps,从而达到保护系统的目的。本篇文章将会介绍一下常用的限流算法以及他们各自的特点。

1、计数器算法

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

Guava平滑限流

具体的伪代码如下:

public class CounterTest {
    public long timeStamp = getNowTime();
    public int reqCount = 0;
    public final int limit = 100; // 时间窗口内最大请求数
    public final long interval = 1000; // 时间窗口ms

    public boolean grant() {
        long now = getNowTime();
        if (now < timeStamp + interval) {
            // 在时间窗口内
            reqCount++;
            // 判断当前时间窗口内是否超过最大请求控制数
            return reqCount <= limit;
        } else {
            timeStamp = now;
            // 超时后重置
            reqCount = 1;
            return true;
        }
    }

    public long getNowTime() {
        return System.currentTimeMillis();
    }
}

这个算法虽然简单,但是有一个十分致命的问题,那就是临界问题,我们看下图:

Guava平滑限流

从上图中我们可以看到,假设有一个恶意用户,他在0:59时,瞬间发送了100个请求,并且1:00又瞬间发送了100个请求,那么其实这个用户在 1秒里面,瞬间发送了200个请求。我们刚才规定的是1分钟最多100个请求,也就是每秒钟最多1.7个请求,用户通过在时间窗口的重置节点处突发请求, 可以瞬间超过我们的速率限制。用户有可能通过算法的这个漏洞,瞬间压垮我们的应用。

聪明的朋友可能已经看出来了,刚才的问题其实是因为我们统计的精度太低。那么如何很好地处理这个问题呢?或者说,如何将临界问题的影响降低呢?我们可以看下面的滑动窗口算法。

滑动窗口

滑动窗口,又称rolling window。为了解决这个问题,我们引入了滑动窗口算法。如果学过TCP网络协议的话,那么一定对滑动窗口这个名词不会陌生。下面这张图,很好地解释了滑动窗口算法:

Guava平滑限流

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

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

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

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

2、令牌桶算法

令牌桶算法是比较常见的限流算法之一,大概描述如下:

1)、所有的请求在处理之前都需要拿到一个可用的令牌才会被处理;

2)、根据限流大小,设置按照一定的速率往桶里添加令牌;

3)、桶设置最大的放置令牌限制,当桶满时、新添加的令牌就被丢弃或者拒绝;

4)、请求达到后首先要获取令牌桶中的令牌,拿着令牌才可以进行其他的业务逻辑,处理完业务逻辑之后,将令牌直接删除;

5)、令牌桶有最低限额,当桶中的令牌达到最低限额的时候,请求处理完之后将不会删除令牌,以此保证足够的限流;

Guava平滑限流

3、漏桶算法

漏桶算法其实很简单,可以粗略的认为就是注水漏水过程,往桶中以一定速率流出水,以任意速率流入水,当水超过桶流量则丢弃,因为桶容量是不变的,保证了整体的速率。

Guava平滑限流

如果,您希望更容易地发现我的新博客,不妨点击一下绿色通道的【 关注我 】。

如果,想给予我更多的鼓励, 求打

因为,我的写作热情也离不开您的肯定支持,感谢您的阅读,我是【 Ruthless 】!

联系或打赏博主【 Ruthless 】!https://www.cnblogs.com/ujq3/p/7221582.html

来源: https://www.cnblogs.com/linjiqin/p/9707713.html

原文  http://www.iigrowing.cn/guava_ping_hua_xian_liu.html
正文到此结束
Loading...