高并发场景下的限流和降级

什么是限流和降级

在开发高并发系统时,有很多手段来保护系统:缓存、降级、限流。

当访问量快速增长、服务可能会出现一些问题(响应超时),或者会存在非核心服 务影响到核心流程的性能时, 仍然需要保证服务的可用性,即便是有损服务。 所以意味着我们在设计服务的时候,需要一些手段或者关键数据进行自动降级,或者配置人工降级的开关。

缓存的目的是提升系统访问速度和增大系统处理的容量,可以说是抗高并发流量的银弹;

降级是当服务出问题或者影响到核心流程的性能则需要暂时屏蔽掉某些功能,等高 峰或者问题解决后再打开;而有些场景并不能用缓存和降级来解决,比如秒杀、抢 购;写服务(评论、下单)、频繁的复杂查询,因此需要一种手段来限制这些场景 的并发/请求量

降级

对于高可用服务的设计,有一个很重要的设计,那就是降级。降级一般有几种实现 手段,自动降级和人工降级

  1. 通过配置降级开关,实现对流程的控制

  2. 前置化降级开关, 基于 OpenResty+配置中心实现降级

  3. 业务降级,在大促的时候,我们会有限保证核心业务的流程可用,也就是下单 支付。同时,我们也会对核心的支付流程采取一些异步化的方式来提升吞吐量

限流

限流的目的是防止恶意请求流量、恶意攻击、或者防止流量超过系统峰值 限流是对资源访问做控制的一个组件或者功能,那么控制这块主要有两个功能:限流策略和熔断策略,对于熔断策略,不同的系统有不同的熔断策略诉求,有得系统希望直接拒绝服务、有的系统希望排队等待、有的系统希望服务降级。限流服务 这块有两个核心概念:资源和策略资源:被流量控制的对象,比如接口策略:限流策略由限流算法和可调节的参数两部份组成

限流的目的是通过对并发访问/请求进行限速或者一个时间窗口内的请求进行限速 来保护系统,一旦达到限制速率则可以拒绝服务(定向到错误页或者告知资源没有 了)、排队或等待(秒杀、下单)、降级(返回兜底数据或默认数据或默认数据,如商品详情页库存默认有货)

限流和降级

滑动窗口协议是传输层进行流控的一种措施,接收方通过通告发送方自己的窗口大小,从而控制发送方的发送速度,从而达到防止发送方发送速度过快而导致自己被淹没的目的。

简单解释下,发送和接受方都会维护一个数据帧的序列,这个序列被称作窗口。发 送方的窗口大小由接受方确定,目的在于控制发送速度,以免接受方的缓存不够大, 而导致溢出,同时控制流量也可以避免网络拥塞。下面图中的 4,5,6 号数据帧已经 被发送出去,但是未收到关联的 ACK,7,8,9 帧则是等待发送。可以看出发送端的 窗口大小为 6,这是由接受端告知的。此时如果发送端收到 4 号 ACK,则窗口的左 边缘向右收缩,窗口的右边缘则向右扩展,此时窗口就向前“滑动了”,即数据帧 10 也可以被发送

动态效果演示

什么是限流和降级

在开发高并发系统时,有很多手段来保护系统:缓存、降级、限流。

当访问量快速增长、服务可能会出现一些问题(响应超时),或者会存在非核心服 务影响到核心流程的性能时, 仍然需要保证服务的可用性,即便是有损服务。 所以意味着我们在设计服务的时候,需要一些手段或者关键数据进行自动降级,或者配置人工降级的开关。

缓存的目的是提升系统访问速度和增大系统处理的容量,可以说是抗高并发流量的银弹;

降级是当服务出问题或者影响到核心流程的性能则需要暂时屏蔽掉某些功能,等高 峰或者问题解决后再打开;而有些场景并不能用缓存和降级来解决,比如秒杀、抢 购;写服务(评论、下单)、频繁的复杂查询,因此需要一种手段来限制这些场景 的并发/请求量

降级

对于高可用服务的设计,有一个很重要的设计,那就是降级。降级一般有几种实现 手段,自动降级和人工降级

  1. 通过配置降级开关,实现对流程的控制

  2. 前置化降级开关, 基于 OpenResty+配置中心实现降级

  3. 业务降级,在大促的时候,我们会有限保证核心业务的流程可用,也就是下单 支付。同时,我们也会对核心的支付流程采取一些异步化的方式来提升吞吐量

限流

限流的目的是防止恶意请求流量、恶意攻击、或者防止流量超过系统峰值 限流是对资源访问做控制的一个组件或者功能,那么控制这块主要有两个功能:限流策略和熔断策略,对于熔断策略,不同的系统有不同的熔断策略诉求,有得系统希望直接拒绝服务、有的系统希望排队等待、有的系统希望服务降级。限流服务 这块有两个核心概念:资源和策略资源:被流量控制的对象,比如接口策略:限流策略由限流算法和可调节的参数两部份组成

限流的目的是通过对并发访问/请求进行限速或者一个时间窗口内的请求进行限速 来保护系统,一旦达到限制速率则可以拒绝服务(定向到错误页或者告知资源没有 了)、排队或等待(秒杀、下单)、降级(返回兜底数据或默认数据或默认数据,如商品详情页库存默认有货)

限流和降级

滑动窗口协议是传输层进行流控的一种措施,接收方通过通告发送方自己的窗口大小,从而控制发送方的发送速度,从而达到防止发送方发送速度过快而导致自己被淹没的目的。

简单解释下,发送和接受方都会维护一个数据帧的序列,这个序列被称作窗口。发 送方的窗口大小由接受方确定,目的在于控制发送速度,以免接受方的缓存不够大, 而导致溢出,同时控制流量也可以避免网络拥塞。下面图中的 4,5,6 号数据帧已经 被发送出去,但是未收到关联的 ACK,7,8,9 帧则是等待发送。可以看出发送端的 窗口大小为 6,这是由接受端告知的。此时如果发送端收到 4 号 ACK,则窗口的左 边缘向右收缩,窗口的右边缘则向右扩展,此时窗口就向前“滑动了”,即数据帧 10 也可以被发送

动态效果演示

漏桶

image-20181127153258192.png

桶本身具有一个恒定的速率往下漏水,而上方时快时慢的会有水进入桶内。当桶还 未满时,上方的水可以加入。一旦水满,上方的水就无法加入。桶满正是算法中的 一个关键的触发条件(即流量异常判断成立的条件)。而此条件下如何处理上方流 下来的水,有两种方式:

  1. 暂时拦截住上方水的向下流动,等待桶中的一部分水漏走后,再放行上方水。

  2. 溢出的上方水直接抛弃 特点

  3. 漏水的速率是固定的

  4. 即使存在注水 burst(突然注水量变大)的情况,漏水的速率也是固定的

令牌桶(能够解决突发流量)

令牌桶算法是网络流量整形(Traffic Shaping)和速率限制(Rate Limiting)中最常使用的一种算法。典型情况下,令牌桶算法用来控制发送到网络上的数据的数目,并允许突发数据的发送。

令牌桶是一个存放固定容量令牌(token)的桶,按照固定速率往桶里添加令牌; 令牌桶算法实际上由三部分组成:两个流和一个桶,分别是令牌流、数据流和令牌桶

image-20181127153946953.png

限流算法的实际应用

Guava 的 RateLimiter 实现

在 Guava 中 RateLimiter 的实现有两种: Bursty 和 WarmUp

bursty

bursty 是基于 token bucket 的算法实现,比如

RateLimiter rateLimiter=RateLimiter.create(permitPerSecond); //创建一个 bursty 实例

rateLimiter.acquire(); //获取 1 个 permit,当令牌数量不够时会阻塞直到获取为止

WarmingUp

  1. 基于 Leaky bucket 算法实现

  2. QPS 是固定的

  3. 使用于需要预热时间的使用场景

//创建一个 SmoothWarmingUp 实例;warmupPeriod 是指预热的时间 
RateLimiter create(double permitsPerSecond, long warmupPeriod, TimeUnit unit) 

RateLimiter rateLimiter =RateLimiter.create(permitsPerSecond,warmupPeriod,timeUnit); 

rateLimiter.acquire();//获取 1 个 permit;可能会被阻塞止到获取到为止 

 <dependency>
     <groupId>com.google.guava</groupId>
     <artifactId>guava</artifactId>
     <version>27.0-jre</version>
</dependency>
public class Token {
    //guava->令牌桶、漏桶
    //bursty(令牌桶)
    RateLimiter rateLimiter=RateLimiter.create(10); //qps是1000

    //漏桶
    RateLimiter rateLimiter1=RateLimiter.create(1000,10, TimeUnit.MILLISECONDS);

    public void doPay(){
        if(rateLimiter.tryAcquire()){
            System.out.println(Thread.currentThread().getName()+"开始执行支付");
        }else {
            System.out.println("系统繁忙");
        }
    }

    public static void main(String[] args) throws IOException {
        Token token=new Token();
        CountDownLatch countDownLatch=new CountDownLatch(1);
        Random random=new Random(10);
        for (int i = 0; i < 20; i++) {
            new Thread(()->{
                try{
                    countDownLatch.await();
                    Thread.sleep(random.nextInt(1000));
                    token.doPay();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            }).start();
        }
        countDownLatch.countDown();
        System.in.read();
    }
}

差异化演示

import com.google.common.util.concurrent.RateLimiter;

import java.util.concurrent.TimeUnit;

public class TokenDemo {
    private int qps;
    private int countOfReq;
    private RateLimiter rateLimiter;

    public TokenDemo(int qps, int countOfReq) {
        this.qps = qps;
        this.countOfReq = countOfReq;
    }

    public TokenDemo processWithTokenBucket() {
        rateLimiter = RateLimiter.create(qps);
        return this;
    }

    //warmupPeriod 是指预热的时间
    public TokenDemo processWithLeakyBucket() {
        rateLimiter = RateLimiter.create(qps, 00, TimeUnit.MILLISECONDS);
        return this;
    }

    private void processRequest() {
        System.out.println("RateLimiter:" + rateLimiter.getClass());
        long start = System.currentTimeMillis();
        for (int i = 0; i < countOfReq; i++) {
            rateLimiter.acquire();
        }
        long end = System.currentTimeMillis() - start;
        System.out.println("处理请求数量:" + countOfReq + "," +
                "耗时:" + end + "," +
                "qps:" + rateLimiter.getRate() + "," +
                "实际 qps:" + Math.ceil(countOfReq / (end / 1000.00)));
    }

    public void doProcess() throws InterruptedException {
        for (int i = 0; i < 20; i = i + 5) {
            TimeUnit.SECONDS.sleep(i);
            processRequest();
        }
    }

    public static void main(String[] args) throws InterruptedException {
        new TokenDemo(50, 100).processWithTokenBucket().doProcess();

        new TokenDemo(50, 100).processWithLeakyBucket().doProcess();
    }
} 

分布式下的限流策略

技术选型
mysql:存储限流策略的参数等元数据 redis+lua:令牌桶算法实现
具体实现
参考 Redisson 中的令牌桶实现逻辑即可

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,271评论 5 476
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,275评论 2 380
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,151评论 0 336
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,550评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,553评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,559评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,924评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,580评论 0 257
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,826评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,578评论 2 320
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,661评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,363评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,940评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,926评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,156评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,872评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,391评论 2 342