标签：流控 代码 一段 请求 机器 比较 无法 接口 attach
流量预警和限流方案中，比较常用的有两种。第一种滑窗模式，通过统计一段时间内的访问次数来进行控制，访问次数达到的某个峰值时进行限流。第二种为并发用户数模式，通过控制最大并发用户数，来达到流量控制的目的。下面来简单分析下两种的优缺点。
1、滑窗模式
模式分析:
在每次有访问进来时，我们判断前N个单位时间内的总访问量是否超过了设置的阈值，并对当前时间片上的请求数+1。
上图每一个格式表示一个固定的时间（比如1s），每个格子一个计数器，我们要获取前5s的请求量，就是对当前时间片i ~ i-4的时间片上计数器进行累加。
这种模式的实现的方式更加契合流控的本质意义。理解较为简单。但由于访问量的不可预见性，会发生单位时间的前半段大量请求涌入，而后半段则拒绝所有请求的情况。（通常，需要可以将单位时间切的足够的小来缓解 ）其次，我们很难确定这个阈值设置在多少比较合适，只能通过经验或者模拟（如压测）来进行估计，即使是压测也很难估计的准确。集群部署中每台机器的硬件参数不同，可能导致我们需要对每台机器的阈值设置的都不尽相同。同一台机子在不同的时间点的系统压力也不一样（比如晚上还有一些任务，或其他的一些业务操作的影响），能够承受的最大阈值也不尽相同，我们无法考虑的周全。
所以滑窗模式通常适用于对某一资源的保护的需求上（或者说是承诺比较合适：我对某一接口的提供者承诺过，最高调用量不超过XX），如对db的保护，对某一服务的调用的控制上。
代码实现思路：
每一个时间片（单位时间）就是一个独立的计数器，用以数组保存。将当前时间以某种方式（比如取模）映射到数组的一项中。每次访问先对当前时间片上的计数器+1，再计算前N个时间片的访问量总合，超过阈值则限流。
@https://www.cnblogs.com/yuhan-TB/p/3765457.html
标签：流控 代码 一段 请求 机器 比较 无法 接口 attach
原文地址：https://www.cnblogs.com/xingzc/p/9846575.html
