❝
如果一个请求完成一笔事务,那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 滑动时间窗口
============
滑动时间窗口算法是目前比较流行的限流算法,主要思想是把时间看做是一个向前滚动的窗口,如下图:
开始的时候,我们把t1t5看做一个时间窗口,每个窗口1s,如果我们定的限流目标是每秒50个请求,那t1t5这个窗口的请求总和不能超过250个。
这个窗口是滑动的,下一秒的窗口成了t2~t6,这时把t1时间片的统计抛弃,加入t6时间片进行统计。这段时间内的请求数量也不能超过250个。
滑动时间窗口的优点是解决了流量计数器算法的缺陷,但是也有2个问题:
-
流量超过就必须抛弃或者走降级逻辑
-
对流量控制不够精细,不能限制集中在短时间内的流量,也不能削峰填谷
1.2.3 漏桶算法
==========
漏桶算法的思想如下图: