比如限制微服务集群单台呆板每秒请求次数，我们还需要针对不同调用方甚至不同接口进行更加细粒度限流：
比如限制 A 调用方对某个服务的某个的接口的每秒最大请求次数。
流
限流中的“流”字该如何解读呢？要限制的指标到底是什么？
不同的场景对“流”的定义也是不同的，可以是网络流量，带宽，每秒处理的事务数 (TPS)，每秒请求数 (hits per second)，并发请求数，
甚至还可能是业务上的某个指标，比如用户在某段时间内允许的最多请求短信验证码次数。
从包管体系稳定可用的角度考量，对于微服务体系来说，最好的一个限流指标是：并发请求数。
通过限制并发处理的请求数量，可以限制任何时刻都不会有过多的请求在消耗资源
，比如：我们通过配置 web 容器中 servlet worker 线程数量为 200，则任何时刻最多都只有 200 个请求在处理，凌驾的请求都会被壅闭排队。
对比 TPS 和 hits per second 的两个指标，我们选择使用 hits per second 作为限流指标。
因为，对 TPS 的限流实际上是无法做的，TPS 表示每秒处理事务数，事务的开始是接收到接口请求，事务的结束是处理完成返回，所以有肯定的时间跨度，假如事务开始限流计数器加一，事务结束限流计数器减一，则就等同于并发限流。
而假如把事务请求接收作为计数时间点，则就退化为按照 hits per second 来做限流，而假如把事务结束作为计数时间点，则计数器的数值并不能代表体系当下以及接下来的体系访问压力。
对 hits per second 的限流是否是一个有效的限流指标呢？答案是肯定的，这个值是可观察可统计的，所以方便配置限流规则，而且这个值在肯定水平上反应体系当前和接下来的性能压力，对于这一指标的限流确实也可以达到限制对体系资源的使用。
有了流的定义之后，我们接下来看几种常用的限流算法：固定时间窗口，滑动时间窗口，令牌桶算法，漏桶算法以及他们的改进版本。
常见算法