[分布式]-限流熔断降级-Toy模板网

这篇具有很好参考价值的文章主要介绍了[分布式]-限流熔断降级。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

限流

限流，顾名思义，限制系统的流量，防止用户过多地访问系统的资源，甚至是恶意地访问，比如恶意爬虫，DDOS 等；同时也防止系统承载过多流量而崩溃，从而对系统运行资源做到一个有效的管理

在分布式系统中，节点之间需要相互调用，如果调用链中一个节点宕机，将会导致整个链路都无法访问，从而造成雪崩问题，使整个系统出现不可用状态，为了解决这种问题，保持高可用的性质，常见处理方式有：超时返回，调用方调用超时直接返回不再无效等待；舱壁模式，限定每个业务能使用的线程数，当多个线程阻塞于同一个服务，后续的线程将不能调用该服务，也就不会被阻塞；熔断降级，将被调用的业务进行熔断降级；以及限流。
前三种更多是在节点宕机被发现后的应对措施，而限流更偏向于一种预防措施

限流规则

QPS 和连接数
传输速率：限制用户下载，访问某些资源的传输速率
黑白名单：将不同 IP 添加到黑白名单，实现 IP 维度的限流策略

限流方案

分布式系统中，主流的限流方案有两种：

网关限流：将限流操作设置在所有流量的入口处，通常是网关
独立中间件限流，将限流服务部署到单独的某台服务器上，其它节点都通过从这里获取限流信息然后确定允许流量或者拒绝流量

限流算法

计数限流

计数限流应该是最简单的限流算法。例如系统限制同时只能处理 100 个请求，那么就维护一个计数器，接受一个请求时计数器加一，处理完毕时计数器减一，且每次请求到来时先判断计数器的值是否超出阈值，是的话拒绝请求

根据系统是单体系统还是分布式系统又可细分为单机限流跟分布式限流。单机限流的话可以使用 Java 中的原子整数作为计数器；分布式限流的可以使用 Redis 中的 incr 命令

计数限流算法的缺陷在于，只考虑了流量的阈值，没有考虑流量的突发性。一小时达到 100 个请求的压力跟 1 秒内达到 100 个请求的压力是完全不同的，后者这种突发性的流量对系统的压力是非常大的，因此需要限制一定时间间隔内的流量大小，引入时间窗口，比如最简单的固定窗口限流

固定窗口

固定窗口算法相比于传统计数限流多了一个时间窗口的概念，计数器在每个固定的时间窗口内，如果计数器的值小于请求阈值，就允许请求访问，同时计数器增一；否则就不允许。每经过一个时间窗口的长度计数器就重置，进入到下一个时间窗口

这种算法看起来确实可以确保每个窗口内的请求数不超出阈值，但却不能确保两个窗口之间的交界区域中的限流，比如阈值设置为每个窗口为 1 s，然后每秒最多 100 个请求，那么如果在第 i 个窗口的后半段有 51 个请求，进入到第 i + 1 个窗口时计数器重置，在第 i + 1 个窗口的前半段有 51 个请求，那么根据算法，这 102 个请求都是会被允许的，但是在第 i 个窗口的后半段跟第 i + 1 个窗口的前半段组成的这个同样为 1s 的时间窗口中却有 102 个请求被允许，不符合限流的阈值要求

所以时间窗口不能固定，需要使用滑动窗口

滑动窗口

滑动窗口中不需要记录每次时间窗口的起始边界，而是在每个请求到来时，根据时间戳来减去时间窗口长度，比如 1 s，然后动态地得到窗口的边界，再判断到达时间戳处于该窗口内的请求数是否超出阈值，从而确定允许或者拒绝该请求。所以该算法需要保存每个请求的到达时间戳，同时需要清除掉窗口长度之前的过时请求的到达时间戳，如果一个窗口长度内的请求数很多，需要花费一定的内存存储开销

这种方法的问题在于：

计算机的时钟受硬件限制，在时间计算上可能存在误差，无法满足较高的时效性要求；
第二是该方法只能满足一定长度的时间窗口内的限流，不能限制集中在极短时间间隔内的流量爆发，因为系统的时间精度可能达不到要求，不能确保流量平滑。而且有的时候资源的限制条件是有多个的，比如 1 s 内不超出 100 个请求，且为了抵御高并发，10 ms 内不超出 5 个请求，这样单个时间窗口的限制就无法满足需求。当然，我们可以通过同时设置多个窗口同时进行计数来达到多限制条件的目的

漏桶算法

为了解决流量突发导致流量不平滑的问题，我们设置一个漏桶，当请求到来时不是直接判断允许或者拒绝，而是先放到桶中，如果桶内存放的请求数量达到桶的容量了再拒绝后续的请求，然后漏桶定时地将桶内的请求放出，由后端服务拿去处理

可以看出，在这种算法中，无论请求产生的速率多大，后端服务拿去处理的速率都是固定的，从而使流量平滑，跟消息队列很类似，削峰填谷。在这里，计算机中的一大定理 —— 一切问题都能通过增加一个中间层来解决，再一次发挥作用

但是 绝对的流量平滑并不一定是好事。有些突发请求，我们是可以接受的，因为需要为了满足用户的体验而尽快处理，只要在系统可以平稳运行的前提下即可。为此，需要令牌桶算法

令牌桶算法

令牌桶算法中同样需要一个漏桶，但放入桶中的不是请求了，而是令牌。令牌会定时地放入漏桶，如果桶中令牌数量超出桶容量，则后续的令牌被丢弃。当有请求到来时，需要先向桶索取令牌，索取成功则被允许可以处理，否则被拒绝。这个思路跟信号量很类似，可以控制某种资源被同时访问的对象数目

当多个请求突发时，假设桶内有充足的令牌，那么这些突发的请求都可以马上获取令牌然后被处理，而不像漏桶算法那样只能以永远固定的速率被处理，所以在应对突发流量时，令牌桶算法的表现更佳

令牌桶算法有个问题就是，在系统刚开始运行时，桶中是没有令牌的，那么一开始的请求就获取不到足够的令牌，无法被处理，但系统刚开始运行时应该是有充足的资源来处理请求的。处理方案就是一开始应该进行令牌桶的预热，预先放入几个令牌，确保系统刚开始运行时的请求能及时被处理

熔断

我们知道，在电路中，保险丝用于保护电路，当电路电流过大时，保险丝就会熔断，从而避免器件损坏。而应用系统中的熔断也类似如此。服务熔断是指调用方访问服务时通过一个断路器作为代理进行调用，而断路器会持续观察被调用服务返回的状态是成功亦或是失败，当失败次数超过设置的阈值时断路器打开，请求就不能到达服务了，从而避免调用方阻塞于调用过程

断路器的状态

断路器有三种状态：

CLOSED：默认状态，断路器观察到被调用服务请求失败比例没有达到阈值，认为被代理服务状态良好
OPEN：断路器观察到请求失败的比例已经达到阈值，于是认为被代理服务故障，打开开关，使请求不再到达被代理服务，而是快速失败
HALF OPEN：断路器打开后后续需要尝试恢复对被代理服务的访问，此时需要切换到半打开状态，然后去请求被代理服务以查看服务是否已经恢复正常。如果确认服务已经恢复正常，则断路器转为 CLOSED 状态，否则转到 OPEN 状态

需要考虑的问题

熔断的时长设置为多长，即超过这个时长后切换到 HALF OPEN 进行重试
针对不同的异常，可能需要定义不同的熔断后处理逻辑
要记录请求失败日志，供监控使用
不一定要等到熔断时长过后才进行重试，可以考虑主动重试，比如对于 connection timeout 这种有可能短期内恢复的问题而造成的熔断，可以用异步线程进行网络检测，比如 telenet，检测到网络畅通时切换到 HALF OPEN 进行重试
设置 补偿接口，让运维人员可以手工关闭断路器。
重试时，可以使用之前失败的请求进行重试，但一定要注意业务上是否允许这样做

降级

在服务被熔断后，一般会让后续的请求走事先配置好的处理方法，这个处理方法就是一个降级逻辑。通常是在系统高并发时，为了使重要的核心业务正常运行，对非核心，非关键的业务不再让其正常地占有部分资源，进行降级处理，从而让出系统资源给核心业务执行文章来源地址https://www.toymoban.com/news/detail-701600.html

到了这里，关于[分布式]-限流熔断降级的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！