服务降级、熔断、限流

熔断请求判断机制算法：使用无锁循环队列计数，每个熔断器默认维护10个bucket，每1秒一个bucket，每个blucket记录请求的成功、失败、超时、拒绝的状态，默认错误超过50%且10秒内超过20个请求进行中断拦截。
熔断恢复：对于被熔断的请求，每隔5s允许部分请求通过，若请求都是健康的（RT<250ms）则对请求健康恢复。
熔断报警：对于熔断的请求打日志，异常请求超过某些设定则报警。

1.2.2 示例

A -> B -> C，如果C出现问题了，那么B熔断了，则A就不用熔断了。

1.3 限流

限流模式主要是提前对各个类型的请求设置最高的QPS阈值，若高于设置的阈值则对该请求直接返回，不再调用后续资源。

常见限流方式

基于请求限流：指从外部请求的角度考虑限流。
基于资源限流：指从系统内部考虑，找到影响性能的关键资源，对其使用上限限制。

1.3.1 算法

漏桶算法：漏桶算法思路很简单，水（请求）先进入到漏桶里，漏桶以一定的速度出水，当水流入速度过大会直接溢出，可以看出漏桶算法能强行限制数据的传输速率。
令牌桶算法：对于很多应用场景来说，除了要求能够限制数据的平均传输速率外，还要求允许某种程度的突发传输。这时候漏桶算法可能就不合适了，令牌桶算法更为适合。
令牌桶算法的原理是系统会以一个恒定的速度往桶里放入令牌，而如果请求需要被处理，则需要先从桶里获取一个令牌，当桶里没有令牌可取时，则拒绝服务。

单机限流：Guava 中的 RateLimiter。在 Guava 的 RateLimiter 中，使用的就是令牌桶算法，允许部分突发流量传输。在其源码里，可以看到能够突发传输的流量等于 maxBurstSeconds * qps。

集群限流：TC 提供的 common-blocking 组件提供此功能。

算法对比：https://blog.csdn.net/xixingzhe2/article/details/128904027

1.3.2 示例

B只允许A以QPS<=5的流量请求，而C却只允许B以QPS<=3的qps请求，那么B给A的设定就有点大，上游的设置依赖下游。而且限流对QPS的配置，可能会随着服务加减机器而变化，最好是能在集群层面配置，自动根据集群大小调整。

2、区别

概念	目的	触发方	触发场景	解决方	处理方案	所有用户表现一致	用户表现
熔断	从可用性可靠性着想，为防止系统的整体缓慢甚至崩溃	某个服务（下游服务）不可用	当失败的调用到一定阈值，如缺省是5秒内20次调用失败，就会启动熔断机制，自动触发	调用方	开启熔断之后，如何实现自动恢复？每隔一段时间，释放一个请求到服务端进行探测，如果后端服务已经恢复，则自动恢复	不一致	用户体验到的是某些功能暂时不可达或不可用
降级	为防止系统的整体缓慢甚至崩溃	服务出问题或者影响到核心流程的性能则需要暂时屏蔽掉	整体负荷比较大，进行人工干预	调用方	取消降级	一致	用户体验到的是某些功能暂时不可达或不可用
限流	通过对并发访问/请求进行限速或者一个时间窗口内的的请求进行限速来保护系统	通过对进行限速来保护系统	超出了服务每分钟的调用量或服务的某个方法调用量	如果是由于当时压测并发数较高引起；视具体情况而定	调大阈值	一致	一旦达到限制速率则可以拒绝服务或等待

3、案例

如果你来设计一个整点限量秒杀系统，包括登录、抢购、支付（依赖支付宝）等核心功能，你会如何设计接口级的故障应对手段？

思路：

降级（丢车保帅）：在秒杀时，通过服务降级把注册、修改个人信息等非核心功能关闭掉。
熔断：支付依赖第三方服务，要设置熔断策略，熔断后要给出友好提示，比如10分钟后再来支付。
限流：抢购下单接口采用限流方式，如抢购1000件商品，则设置2000大小的队列，请求超过2000后直接拒绝掉。

参考：

服务降级、熔断、限流的区别_会思考的男人的博客-CSDN博客_服务熔断和服务降级和服务限流

压力测试术语之熔断、降级、限流-布布扣-bubuko.com

服务降级，服务熔断，服务限流 - 巍巍的个人页面 - OSCHINA - 中文开源技术交流社区

熔断，限流，降级一些理解 - 简书

本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)