Dubbo源码解析（六）-限流及熔断降级原理

一 前文

        提供服务暴露的接口，在流量低的情况或许并不需要考虑限流，因为在数据库或缓存的允许下就能正常的工作，但是当调用突然飙升的时候，那么就会出现异常情况，比如数据库的连接池和线程池就是一种限流手段，通过限制只有指定数量的工作线程，其他线程进行队列等待或是进行抛弃。

二 分布式中主要使用的技术

       目前和dubbo一起运用较多的为Alibaba Sentinel，而SpringCloud中主要是运用了Hystrix（并发线程模式）。

三 限流实现

限流实现主要有1、计数器算法，2、滑动窗口算法，3、令牌桶算法，4、漏桶限流算法。令牌桶和漏桶

3.1 计数器算法

计算器算法，最简单的一种算法，原理就是在指定周期内只能执行n个请求，超过n的请求直接限流。假设周期为1分钟，最多执行100个请求。1-60s 最多100个请求，同时60-120s也最多100个请求，但是在30s和60s期间执行着50个请求，60s-90s期间执行着51个请求，这时候计数器是根据每分钟进行重置为0，那么他并未达到限流的条件，因为在60s的时候他已经重置为0了，但实际上调用的却是101个请求，导致限流局部失效。

3.2 滑动窗口算法

为了解决计数器算法的局部未生效临界问题，引入了滑动窗口算法。以下图位列，将一个周期内分为4块，每次只能执行4个窗口数量的请求，每次往前移动一块，可以重新统计当前4个窗口的请求数，进行解决对应的临界值问题。

Sentinel运用的就是滑动窗口算法。

3.3 令牌桶

也就是令牌+桶进行实现限流，令牌会根据一定的速度生成，而其中桶用于存放对应的令牌，当桶的容量满的时候，不再往桶中放入令牌，而每次请求都会消耗一定的令牌，当请求消耗的速度大于令牌生成的速度之后，就会限流。

3.4 漏桶限流

   对请求速度不做限制，但是限制了处理的速度恒定速度的限流算法，如消息中间件，无论生产者的请求量，消息的最终消费由消费者决定。

 

四 熔断和降级

4.1 熔断

服务A->服务B->服务C

个人理解就是当某个提供服务的服务端异常的时候，但是所有请求还是过来，这时候就会出现所有的前驱调用服务端，都在等待该服务端的响应，久而久之造成了服务雪崩。也就是当服务C异常会导致，服务B一直等待，然后请求一多导致服务B也异常，一直到整条线都崩溃，服务雪崩的时候没有一条服务器是无辜的，那么此时就需要为那些异常的服务器，实现直接返回异常进行熔断。（通常基于异常比例进行判断是否熔断）

4.2 降级

      降级更像是为了让服务调用方有更好的体验，比如调用突然增多的时候，会导致部分请求可能被限流或是熔断等原因，这时候需要给用户一个稍微友好的提示。如抢购的时候很多会提示稍后再试等。

五 Sentinel

限流规则：QPS模式或是并发线程模式

保护规则：流量控制规则、熔断降级规则、系统保护规则、来源访问控制规则、热点参数规则

5.1 并发线程数

Hystrix解决方案：不同的业务逻辑使用不同的线程池来隔离业务之间的资源争抢问题但是会造成线程数量过多时的上下文切换问题。

Sentinel解决方案：通过统计线程数与用户设置的阈值进行比较，如果小于等于阈值则放行；大于阈值则进行限流策略。统计的模型还是基于滑动时间口

5.2 QPS流量控制

QPS代表Queries Per Second每秒的查询数，当QPS达到限流的阈值就会促发限流策略。

5.3 限流策略

直接拒绝（默认策略）、匀速排队（相当于漏桶限流算法）、预热（请求数量逐步递增）

5.4 熔断策略

1、平均响应时间，当该时间超过阈值直接熔断

2、异常比例，异常总数占总量比超过阈值

3、异常数