10张图带你彻底搞懂限流、熔断、服务降级，真香警告

❝

如果一个请求完成一笔事务，那TPS和HPS是等同的。但在分布式场景下，完成一笔事务可能需要多次请求，所以TPS和HPS指标不能等同看待。

❞

1.1.3 QPS

=========

服务端每秒能够响应的客户端查询请求数量。

❝

如果后台只有一台服务器，那HPS和QPS是等同的。但是在分布式场景下，每个请求需要多个服务器配合完成响应。

❞

❝

目前主流的限流方法多采用HPS作为限流指标。

❞

1.2 限流方法

========

1.2.1 流量计数器

===========

这是最简单直接的方法，比如限制每秒请求数量100，超过100的请求就拒绝掉。

但是这个方法存在2个明显的问题：

• 单位时间(比如1s)很难把控，如下图：这张图上，从下面时间看，HPS没有超过100，但是从上面看HPS超过100了。

• 有一段时间流量超了，也不一定真的需要限流，如下图，系统HPS限制50，虽然前3s流量超了，但是如果读超时时间设置为5s，并不需要限流。

1.2.2 滑动时间窗口

============

滑动时间窗口算法是目前比较流行的限流算法，主要思想是把时间看做是一个向前滚动的窗口，如下图：

开始的时候，我们把t1_{t5看做一个时间窗口，每个窗口1s，如果我们定的限流目标是每秒50个请求，那t1}t5这个窗口的请求总和不能超过250个。

这个窗口是滑动的，下一秒的窗口成了t2~t6，这时把t1时间片的统计抛弃，加入t6时间片进行统计。这段时间内的请求数量也不能超过250个。

滑动时间窗口的优点是解决了流量计数器算法的缺陷，但是也有2个问题：

• 流量超过就必须抛弃或者走降级逻辑

• 对流量控制不够精细，不能限制集中在短时间内的流量，也不能削峰填谷

1.2.3 漏桶算法

==========

漏桶算法的思想如下图：