匀速排队限流
匀速排队限流是限流算法中的一种，它是基于漏桶算法实现的。匀速排队限流算法主要提供了一种削峰填谷的限流算法。它帮助服务端能够在流量洪峰到达时，还能保证一个匀速处理的状态，以保护服务端不被冲垮，此为削峰。这种方法不是让超过限流阈值的请求立刻失败，而是给予一定的排队等待时间，超过等待时间才会立刻失败，此为填谷。如下图所示：
漏桶算法是一种基于类比的算法，它将请求类比为水滴，请求打到服务端类比为水滴流入一个水桶。这个水桶能够限定水的滴出速度，即当水量较小时，水将会匀速滴出水桶，稍微多一点的水量也会存在水桶内，等待滴出。这种情况相当于请求量较小时，请求会被服务端匀速处理，偶尔密集的请求也会进行排队来等待服务端处理，如下图(a)所示。而当时某个时间段水量很大，导致水桶无法容纳过多的水时，水将直接溢出，这种情况相当于请求量激增，需要排队等待的请求过多，此时超出排队时间的部分请求，将立刻失败，如下图(b)所示。
匀速排队限流算法是基于漏桶算法的原理实现的，它根据匀速排队限流规则指定“漏桶”出水的速度，根据配置的最大排队时间指定“漏桶”的大小。因此，匀速排队限流算法将遇到一下几种情况进行分别处理：
- 请求速率小于“漏桶”出水速率。这种情况下，漏桶中不会积水，所有的请求都会被马上处理。如下图所示，请求1-4都将重新开启时间窗口，并马上被服务端处理。
- 请求速率大于“漏桶”出水速率，但等待时间小于最大等待时间。此时时间窗口内进来的请求，将会等待一段时间，直到下一个时间窗口来临时才会被服务端处理。如下图所示，Req 1 开启一个时间窗口，在这个时间窗口内，其他请求将不会被处理。而 Req 2 在这个时间窗口内进入，此时它将等待第一个时间窗口结束，才会开启第二个时间窗口，并被服务端处理。同理，Req 3-6 分别将在第三个到第六个时间窗口被服务端处理。从用户侧看，橙色是请求发生的时间戳，黄色代表请求被处理的时间戳，请求被处理的时间间隔为时间窗口的长度，也就是“漏桶”出水的速度，是匀速的。
- 请求速率大于“漏桶”出水速率，且等待时间大于最大等待时间。如下图所示，Req 1-4 和上一种场景类似，将被服务端匀速排队处理。而Req 5-7 由于等待时间超过设定的最大等待时间，因此将直接失败，不被服务端处理。后续到来的 Req 8-9 又将会被服务端正常地匀速排队处理。
