须明白”限”是什么,”流”又是什么。
我们在讨论限流时一般将其解释为流量速率限制 (Rate Limit),即对于一段时间内超出指
定通过阈值的流量进行控制,而根据控制方案的不同,又可分为:
拒绝式限流:对于超出阈值的流量,直接拒绝,返回失败。例如对于 HTTP 请求,可以
直接返回 429 (Too Many Requests) ;如果在微服务中,则可能会启用降级策略。
阻塞式限流:对于超出阈值的流量,可以令它们阻塞或入队,使得这部分的请求阻塞等待,
直到当前系统被使用的额度回归到阈值以下。
当我们选定了控制方案后,就确定了”限”字的含义。但”流”又是什么呢?换句话说,我们
所限制的流量到底是什么?
被限制的”流”在不同的业务场景中有着不同的含义,如用户的发布贴子的速率、同时在线
的房间人数、网盘的下载速率等。
而为了限制这些不同的”流”,我们需要使用对应的流量指标来统计它们,其中我们可以使
用 TPS (Transactions per second) 或 QPS (Queries per second) 作为指标以进行统计,前者为
每秒事务数,后者为每秒查询数。而在”请求-响应”系统中,我们一般更倾向于使用 RPS
(requests per second) 作为流量限制的指标。
为什么我们倾向于 RPS 而不是 TPS ?
TPS 代表着每秒的事务数量,而事务含义为”一个实体执行的原子操作”(至少在逻辑上
需要是原子的)。在业务上,我们当然希望知道一个完整业务操作的 TPS,但在业务的完成
上由于用户行为的不可预知,一个事务完成的具体消耗时间很难被准确的测量。所以我们只
好退而求其次,使用相对容易被监控且准确的 RPS。
除了 TPS、QPS、RPS 外,还有些其他常用的流量限制指标。例如在我们提到的”流”的
限制业务场景中,除了第一个业务可以直接使用 RPS 作为流量限制指标外,第二个则需要
以在线 IP 作为指标、第三个需要以一段时间内的 TCP\UDP 的报文大小作为监控指标,根
据不同的业务,你可以选择不同的限流算法来使用你选定的流量监控指标。
限流算法们
在确定好控制策略和流量监测指标后,接下来就可以讨论限流的基本策略了。
首先,我们先来思考一下怎么样的限流算法才算是一个好的限流算法,如果算法的好坏无
法评判那么我们将无法挑选出最好的算法。
评论0
最新资源