熔断和限流 及其限流算法

近期接触云原生，涉及微服务模块，第一个任务是对微服务限流&熔断组件进行调研，最终决定学习Sentinel组件。为了加强学习效果，定期对学习内容进行回顾总结。

本节主要介绍限流&熔断概念，以及常见限流算法。

若有不对之处，请予指正，不胜感激。

为什么微服务需要限流&熔断?

微服务有负载均衡策略，来保障系统的整体高效运行，但由于网络、某个时间段请求过大或微服务自身等原因，会导致微服务无法百分之百可用。此时就需要启用限流、熔断等微服务自理策略，来保障系统的运行。

什么是微服务限流&熔断？

什么是微服务限流？

微服务限流是指在规定的时间段内限制服务的请求量，以保护系统。主要作用是防止突发流量而导致系统崩溃，比如秒杀、抢购等场景，就需要对系统中微服务进行限流。

现实中限流例子：银行取号系统。

什么是微服务熔断?

在微服务架构中，微服务之间解耦，一个应用可能用到多个微服务，这就带来一个问题，假如微服务A->B->C，微服务B和C又调用其他微服务。如果调用链上某个微服务的调用相应时间过长或不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的”雪崩效应“，熔断机制是对应雪崩效应的一种微服务保护机制。

当调用链路中的某个微服务响应有延迟或长时间不可用，系统就会熔断对该节点微服务的调用，快速返回错误信息。当监控到该微服务正常工做后，再次恢复该调用链路。

现实中熔断例子：（1）电表熔断器。（2）股票交易中，若是股票涨跌幅过大，也会采用熔断机制，暂停交易，来控制交易风险。

微服务的限流、降级、熔断等容错机制不可避免回造成用户请求失败或变慢，从而在一定程度上影响用户体验，所以策略的制定需要以系统压测的结果为参考，并在用户体验与系统稳定性之间进行平衡取舍。

常见限流算法

计数器、固定窗口，滑动窗口、漏桶、令牌桶等限流算法。

计数器限流算法

实现：例如系统能同时处理100个请求，那么可以在保存一个计数器，处理一个请求，计数器+1；一个请求完毕，计数器-1，每次请求进来的时候，先判断计数器的值，如果超过阈值则直接拒绝。支持单机限流和集群限流。

优点：实现简单，单机例如Java的Atomic等原子类就可实现，集群则通过Redis的incr操作就能实现。

缺点：无法应对突发的流量增长，例如我们允许的阈值是1W，此时计数器的值是0，那么当1W个请求瞬时全部进来时候，服务就顶不住。

固定窗口限流算法

实现：以一段时间内的访问量作为限流的依据，计数器每过一个时间窗就自动重置。规则如下：

1. 请求次数小于阈值，允许访问，计数器加1；

2. 请求次数大于阈值，拒绝访问；

3. 本时间窗口过了以后，计数器自动清零。

优点：在一定程度上，可以应对突发流量。

缺点：窗口是固定的额，存在固定窗口的临界问题。

滑动窗口限流算法

实现：相对于固定窗口，需要映入计数器外，还需要额外记录时间窗口内每个请求到达的时间点。

以窗口时间为1s为例，规则如下：

1. 记录每次请求的时间；

2. 统计每次请求的时间向前推1s这个时间窗内的请求数，且1s前的数据可以删除；

3. 统计的请求数小于阈值则记录该请求的时间，并允许通过，反之则拒绝该请求。

缺点：滑动窗口也无法解决短时间之内集中流量的冲击。

优点：解决了固定窗口临界值的问题，可以任意时间窗口内不会超过限流阈值。

漏桶算法

思路：水（请求）先进入漏桶里，漏桶以一定的速度出水，当水流速度过大，直接溢出，然后就拒绝请求，可以看出漏桶算法能强行限制数据的传输速率。

优点：强制限制流量匀速进行。宽进严出，无论请求的速率多大，底部的处理速度都匀速进行。类似消息队列的处理机制，所以一般来说漏桶算法也是由队列来实现的。

缺点：我们往往希望在保持系统稳定的同时，能更快地处理用户请求以提升用户体验，而不是按部就班佛系工作。

令牌桶算法

思路：系统会按恒定1/QPS时间间隔（如果QPS=100，则间隔是10ms）往桶里加入令牌（想象和漏洞漏水相反，有个水龙头在不断的加水），如果桶已经满了就不再加了。新请求来临时，会各自拿走一个令牌，如果没有令牌可拿了就阻塞或者拒绝服务。

允许规则：

1. 定速的向桶里放入令牌；

2. 令牌数量超过桶的限制，则丢弃；

3. 请求来了与向桶中索取令牌，索取成功则通过被处理，否则拒绝。

优点：允许一定程度的突发流量。在突发流量时不会向漏桶那样匀速的处理，而是在短时间内请求可以同时取走桶中的令牌，并及时的被服务器处理，所以在应对突发流量场景下，令牌桶表现更强。