高并发架构设计之限流

一、引言

再强大的系统，也怕流量短事件内集中爆发，就像银行怕挤兑一样，所以，高并发另一个必不可少的模块就是限流。限流是一种通过控制请求的速率或数量来保护系统免受过载的技术。流控的精髓是限制单位时间内的请求量，最大程度保障系统的可靠性及可用性。

二、限流算法

限流是在高并发环境下，为了保护系统的稳定性和可用性而引入的一种策略。通过限制并发请求的数量或频率，可以防止系统被过多的请求压垮或耗尽资源。

常见的流控算法包括：固定窗口、滑动窗口、漏桶、令牌桶、滑动日志等算法。

2.1 固定窗口算法（计数器）

固定窗口限流算法（Fixed Window Rate Limiting Algorithm）是一种最简单的限流算法，其原理是在固定时间窗口(单位时间)内限制请求的数量。

原理

固定窗口是最简单的流控算法。即，给定时间窗口，维护一个计数器用于统计访问次数，并实现以下规则：

1. 如果访问次数小于阈值，则允许访问，访问次数+1；
2. 如果访问次数超出阈值，则限制访问，访问次数不增；
3. 如果超过了时间窗口，计数器清零，并重置清零后的首次成功访问时间为当前时间。

适用场景

• 保护后端服务免受大流量冲击，避免服务崩溃；
• 对 API 调用进行限制，保证公平使用；
• 防止恶意用户对服务进行洪水攻击；

实现方式

public class FixedWindowRateLimiter {private static int counter = 0;  // 统计请求数private static long lastAcquireTime = 0L;private static final long windowUnit = 1000L; // 假设固定时间窗口是1000msprivate static final int threshold = 10; // 窗口阀值是10public synchronized boolean tryAcquire() {long currentTime = System.currentTimeMillis();  // 获取系统当前时间if (currentTime - lastAcquireTime > windowUnit) {  // 检查是否在时间窗口内counter = 0;  // 计数器清零lastAcquireTime = currentTime;  // 开启新的时间窗口}if (counter < threshold) {  // 小于阀值counter++;  // 计数器加1return true;  // 获取请求成功}return false;  // 超过阀值，无法获取请求}
}

使用了一个静态的counter变量来记录请求数量，lastAcquireTime变量记录上一次获取请求的时间戳。windowUnit表示固定时间窗口的长度，threshold则表示在时间窗口内的请求数阀值。

tryAcquire()方法使用了synchronized关键字来实现线程安全，在方法中进行以下操作：

• 获取当前系统时间 currentTime。
• 检查当前时间是否距离上一次获取请求的时间超过了时间窗口长度 windowUnit。如果超过了时间窗口，则将计数器 counter 清零，并更新 lastAcquireTime 为当前时间，表示进入新的时间窗口。
• 如果计数器 counter 小于阀值 threshold，则将计数器加1，并返回true表示获取请求成功。
• 如果计数器已经达到或超过阀值，则返回false表示无法获取请求。

优劣分析

优点

• 固定窗口算法非常简单，易于实现和理解。
• 性能高

缺点

• 存在明显的临界问题
• eg:比如: 假设限流阀值为5个请求，单位时间窗口是1s，如果我们在单位时间内的前0.8-1s和1-1.2s，分别并发5个请求。虽然都没有超过阀值，但是如果算0.8-1.2s内的，则并发数高达10，已经超过单位时间1s不超过5阀值的定义了。

 2.2 滑动窗口算法

为了解决临界突变问题，可以引入滑动窗口。即：把大的时间窗口拆分成若干粒度更细的子窗口，每个子窗口独立统计，按子窗口时间滑动，统一限流。当滑动窗口的格子周期划分的越多，那么滑动窗口的滚动就越平滑，限流的统计就会越精确。

原理

将单位时间周期分为n个小周期，分别记录每个小周期内接口的访问次数，并且根据时间滑动删除过期的小周期。它可以解决固定窗口临界值的问题。

假设单位时间还是1s，滑动窗口算法把它划分为5个小周期，也就是滑动窗口（单位时间）被划分为5个小格子。每格表示0.2s。每过0.2s，时间窗口就会往右滑动一格。然后呢，每个小周期，都有自己独立的计数器，如果请求是0.83s到达的，0.8~1.0s对应的计数器就会加1。

假设我们1s内的限流阀值还是5个请求，0.8~1.0s内（比如0.9s的时候）来了5个请求，落在黄色格子里。

时间过了1.0s这个点之后，又来5个请求，落在紫色格子里。如果是固定窗口算法，是不会被限流的，但是滑动窗口的话，每过一个小周期，它会右移一个小格。过了1.0s这个点后，会右移一小格，当前的单位时间段是0.2~1.2s，这个区域的请求已经超过限定的5了，已触发限流啦，实际上，紫色格子的请求都被拒绝。

实现方式

import java.util.LinkedList;
import java.util.Queue;
public class SlidingWindowRateLimiter {private Queue<Long> timestamps; // 存储请求的时间戳队列private int windowSize; // 窗口大小，即时间窗口内允许的请求数量private long windowDuration; // 窗口持续时间，单位：毫秒public SlidingWindowRateLimiter(int windowSize, long windowDuration) {this.windowSize = windowSize;this.windowDuration = windowDuration;this.timestamps = new LinkedList<>();}public synchronized boolean tryAcquire() {long currentTime = System.currentTimeMillis(); // 获取当前时间戳// 删除超过窗口持续时间的时间戳while (!timestamps.isEmpty() && currentTime - timestamps.peek() > windowDuration) {timestamps.poll();}if (timestamps.size() < windowSize) { // 判断当前窗口内请求数是否小于窗口大小timestamps.offer(currentTime); // 将当前时间戳加入队列return true; // 获取请求成功}return false; // 超过窗口大小，无法获取请求}
}

代码解读

在以上代码中，使用了一个Queue（队列）来存储请求的时间戳。构造函数中传入窗口大小 windowSize 和窗口持续时间 windowDuration。tryAcquire()方法使用了synchronized关键字来实现线程安全，在方法中进行以下操作：

• 获取当前系统时间戳 currentTime。
• 从队列中删除超过窗口持续时间的时间戳，确保队列中只保留窗口内的时间戳。
• 判断当前窗口内请求数是否小于窗口大小 windowSize。

如果小于窗口大小，将当前时间戳加入队列，并返回true表示获取请求成功。如果已经达到或超过窗口大小，表示请求数已满，返回false表示无法获取请求。

使用这个滑动窗口限流算法，可以限制在一定时间窗口内的请求频率，超过窗口大小的请求会被限制。您可以根据实际需求和业务场景进行调整和使用。

适用场景

同固定窗口的场景，且对流量限制要求较高的场景，需要更好地应对突发流量。

优劣分析

优势

• 简单易懂
• 精度高（通过调整时间窗口的大小来实现不同的限流效果）
• 可扩展性强（可以非常容易地与其他限流算法结合使用）

劣势

• 突发流量无法处理（无法应对短时间内的大量请求，但是一旦到达限流后，请求都会直接暴力被拒绝。这样我们会损失一部分请求，这其实对于产品来说，并不太友好），需要合理调整时间窗口大小。

2.3 漏桶算法

基于（出口）流速来做流控。在网络通信中常用于流量整形，可以很好地解决平滑度问题。

特点

• 可以以任意速率流入水滴到漏桶（流入请求）
• 漏桶具有固定容量，出水速率是固定常量（流出请求）
• 如果流入水滴超出了桶的容量，则流入的水滴溢出（新请求被拒绝）

原理

思想：将数据包看作是水滴，漏桶看作是一个固定容量的水桶，数据包像水滴一样从桶的顶部流入桶中，并通过桶底的一个小孔以一定的速度流出，从而限制了数据包的流量

工作原理：对于每个到来的数据包，都将其加入到漏桶中，并检查漏桶中当前的水量是否超过了漏桶的容量。如果超过了容量，就将多余的数据包丢弃。如果漏桶中还有水，就以一定的速率从桶底输出数据包，保证输出的速率不超过预设的速率，从而达到限流的目的。

代码实现

public class LeakyBucketRateLimiter {private long capacity; // 漏桶容量，即最大允许的请求数量private long rate; // 漏水速率，即每秒允许通过的请求数量private long water; // 漏桶当前水量private long lastTime; // 上一次请求通过的时间戳public LeakyBucketRateLimiter(long capacity, long rate) {this.capacity = capacity;this.rate = rate;this.water = 0;this.lastTime = System.currentTimeMillis();}public synchronized boolean tryAcquire() {long now = System.currentTimeMillis();long elapsedTime = now - lastTime;// 计算漏桶中的水量water = Math.max(0, water - elapsedTime * rate / 1000);if (water < capacity) { // 判断漏桶中的水量是否小于容量water++; // 漏桶中的水量加1lastTime = now; // 更新上一次请求通过的时间戳return true; // 获取请求成功}return false; // 漏桶已满，无法获取请求}
}

代码解读

在以上代码中，capacity表示漏桶的容量，即最大允许的请求数量；rate表示漏水速率，即每秒允许通过的请求数量。water表示漏桶中当前的水量，lastTime表示上一次请求通过的时间戳。tryAcquire()方法使用了synchronized关键字来实现线程安全，在方法中进行以下操作：

1. 获取当前系统时间戳 now。
2. 计算从上一次请求通过到当前的时间间隔 elapsedTime。
3. 根据漏水速率和时间间隔，计算漏桶中的水量。
4. 判断漏桶中的水量是否小于容量。

如果小于容量，漏桶中的水量加1，更新上一次请求通过的时间戳，并返回true表示获取请求成功。如果已经达到或超过容量，漏桶已满，返回false表示无法获取请求。

适用场景

一般用于保护第三方的系统，比如自身的系统需要调用第三方的接口，为了保护第三方的系统不被自身的调用打垮，便可以通过漏斗算法进行限流，保证自身的流量平稳的打到第三方的接口上。

优劣分析

优势

• 可以平滑限制请求的处理速度，避免瞬间请求过多导致系统崩溃或者雪崩。
• 可以控制请求的处理速度，使得系统可以适应不同的流量需求，避免过载或者过度闲置。
• 可以通过调整桶的大小和漏出速率来满足不同的限流需求，可以灵活地适应不同的场景。

劣势

• 需要对请求进行缓存，会增加服务器的内存消耗。
• 对于流量波动比较大的场景，需要较为灵活的参数配置才能达到较好的效果。
• 但是面对突发流量的时候，漏桶算法还是循规蹈矩地处理请求，这不是我们想看到的啦。流量变突发时，我们肯定希望系统尽量快点处理请求，提升用户体验嘛。

2.4 令牌桶算法

基于（入口）流速来做流控的一种限流算法。

原理

该算法维护一个固定容量的令牌桶，每秒钟会向令牌桶中放入一定数量的令牌。当有请求到来时，如果令牌桶中有足够的令牌，则请求被允许通过并从令牌桶中消耗一个令牌，否则请求被拒绝。

 实现方式

import java.util.concurrent.ScheduledExecutorService;
import java.util.concurrent.ScheduledThreadPoolExecutor;import java.util.concurrent.TimeUnit;
public class TokenBucketRateLimiter {private long capacity; // 令牌桶容量，即最大允许的请求数量private long rate; // 令牌产生速率，即每秒产生的令牌数量private long tokens; // 当前令牌数量private ScheduledExecutorService scheduler; // 调度器public TokenBucketRateLimiter(long capacity, long rate) {this.capacity = capacity;this.rate = rate;this.tokens = capacity;this.scheduler = new ScheduledThreadPoolExecutor(1);scheduleRefill(); // 启动令牌补充任务}private void scheduleRefill() {scheduler.scheduleAtFixedRate(() -> {synchronized (this) {tokens = Math.min(capacity, tokens + rate); // 补充令牌，但不超过容量}}, 1, 1, TimeUnit.SECONDS); // 每秒产生一次令牌}public synchronized boolean tryAcquire() {if (tokens > 0) { // 判断令牌数量是否大于0tokens--; // 消耗一个令牌return true; // 获取请求成功}return false; // 令牌不足，无法获取请求}
}

代码解读

capacity表示令牌桶的容量，即最大允许的请求数量；rate表示令牌产生速率，即每秒产生的令牌数量。tokens表示当前令牌数量，scheduler是用于调度令牌补充任务的线程池。在构造方法中，初始化令牌桶的容量和当前令牌数量，并启动令牌补充任务scheduleRefill()。

scheduleRefill()方法使用调度器定期执行令牌补充任务，每秒补充一次令牌。在补充任务中，通过加锁的方式更新令牌数量，确保线程安全。补充的令牌数量为当前令牌数量加上产生速率，但不超过令牌桶的容量。

tryAcquire()方法使用synchronized关键字来实现线程安全，在方法中进行以下操作：

1.判断令牌数量是否大于0。

• 如果令牌数量大于0，表示令牌足够，消耗一个令牌，并返回true表示获取请求成功。
• 如果令牌数量为0，表示令牌不足，返回false表示无法获取请求。

Guava的RateLimiter限流组件，就是基于令牌桶算法实现的。

适用场景

一般用于保护自身的系统，对调用者进行限流，保护自身的系统不被突发的流量打垮。如果自身的系统实际的处理能力强于配置的流量限制时，可以允许一定程度的流量突发，使得实际的处理速率高于配置的速率，充分利用系统资源。

优劣分析

优势

• 稳定性高：令牌桶算法可以控制请求的处理速度，可以使系统的负载变得稳定。
• 精度高：令牌桶算法可以根据实际情况动态调整生成令牌的速率，可以实现较高精度的限流。
• 弹性好：令牌桶算法可以处理突发流量，可以在短时间内提供更多的处理能力，以处理突发流量。

劣势

• 实现复杂：相对于固定窗口算法等其他限流算法，令牌桶算法的实现较为复杂。对短时请求难以处理：在短时间内有大量请求到来时，可能会导致令牌桶中的令牌被快速消耗完，从而限流。这种情况下，可以考虑使用漏桶算法。
• 时间精度要求高：令牌桶算法需要在固定的时间间隔内生成令牌，因此要求时间精度较高，如果系统时间不准确，可能会导致限流效果不理想。

2.5 滑动日志算法（比较冷门）

滑动日志限速算法需要记录请求的时间戳，通常使用有序集合来存储，我们可以在单个有序集合中跟踪用户在一个时间段内所有的请求。

原理

滑动日志算法可以用于实现限流功能，即控制系统在单位时间内处理请求的数量，以保护系统免受过载的影响。以下是滑动日志算法用于限流的原理：

1. 划分时间窗口：将时间划分为固定的时间窗口，例如每秒、每分钟或每小时等。
2. 维护滑动窗口：使用一个滑动窗口来记录每个时间窗口内的请求次数。这个滑动窗口可以是一个固定长度的队列或数组。
3. 请求计数：当一个请求到达时，将其计数加一并放入当前时间窗口中。
4. 滑动：随着时间的流逝，滑动窗口会根据当前时间窗口的长度，移除最旧的请求计数，并将新的请求计数添加到最新的时间窗口中。
5. 限流判断：在每个时间窗口结束时，统计滑动窗口中的请求计数总和，并与预设的阈值进行比较。如果总请求数超过阈值，则触发限流处理。
6. 限流处理：一旦触发限流，可以采取不同的处理策略，如拒绝请求、延迟处理、返回错误信息等。具体的限流策略可以根据实际情况进行选择。

通过滑动日志算法进行限流，可以实现对单位时间内的请求进行精确控制。它基于实时统计的方式，能够动态地适应请求流量的变化，并且在内存使用上比较高效。同时，通过调整时间窗口的长度和阈值的设置，可以灵活地控制限流的精度和灵敏度。

import java.util.LinkedList;
import java.util.List;
public class SlidingLogRateLimiter {private int requests; // 请求总数private List<Long> timestamps; // 存储请求的时间戳列表private long windowDuration; // 窗口持续时间，单位：毫秒private int threshold; // 窗口内的请求数阀值public SlidingLogRateLimiter(int threshold, long windowDuration) {this.requests = 0;this.timestamps = new LinkedList<>();this.windowDuration = windowDuration;this.threshold = threshold;    }public synchronized boolean tryAcquire() {long currentTime = System.currentTimeMillis(); // 获取当前时间戳// 删除超过窗口持续时间的时间戳while (!timestamps.isEmpty() && currentTime - timestamps.get(0) > windowDuration) {timestamps.remove(0);requests--;}if (requests < threshold) { // 判断当前窗口内请求数是否小于阀值timestamps.add(currentTime); // 将当前时间戳添加到列表requests++; // 请求总数增加return true; // 获取请求成功}return false; // 超过阀值，无法获取请求}
}

代码解读：

在以上代码中，requests表示请求总数，timestamps用于存储请求的时间戳列表，windowDuration表示窗口持续时间，threshold表示窗口内的请求数阀值。

在构造函数中传入窗口内的请求数阀值和窗口持续时间。

tryAcquire()方法使用了synchronized关键字来实现线程安全，在方法中进行以下操作：

1. 获取当前系统时间戳 currentTime。
2. 删除超过窗口持续时间的时间戳，同时更新请求总数。
3. 判断当前窗口内请求数是否小于阀值。

如果小于阀值，将当前时间戳添加到列表，请求总数增加，并返回true表示获取请求成功。如果已经达到或超过阀值，表示请求数已满，返回false表示无法获取请求。

使用这个滑动日志限流算法，可以限制在一定时间窗口内的请求频率，超过阀值的请求会被限制。您可以根据实际需求和业务场景进行调整和使用。

适用场景

优势

• 滑动日志能够避免突发流量，实现较为精准的限流；
• 更加灵活，能够支持更加复杂的限流策略 如多级限流，每分钟不超过100次，每小时不超过300次，每天不超过1000次，我们只需要保存最近24小时所有的请求日志即可实现。

劣势

• 占用存储空间要高于其他限流算法。

三、常用工具

3.1 RateLimiter（单机）

基于令牌桶算法实现的一个多线程限流器，它可以将请求均匀的进行处理，当然他并不是一个分布式限流器，只是对单机进行限流。它可以应用在定时拉取接口数。通过aop、filter、Interceptor 等都可以达到限流效果。

用法

以下是一个基本的 RateLimiter 用法示例：

import com.google.common.util.concurrent.RateLimiter;
public class RateLimiterDemo {public static void main(String[] args) {// 创建一个每秒允许2个请求的RateLimiterRateLimiter rateLimiter = RateLimiter.create(2.0);while (true) {// 请求RateLimiter一个令牌rateLimiter.acquire();// 执行操作doSomeLimitedOperation();}}private static void doSomeLimitedOperation() {// 模拟一些操作System.out.println("Operation executed at: " + System.currentTimeMillis());}
}

在这个例子中，RateLimiter.create(2.0) 创建了一个每秒钟只允许2个操作的限速器。rateLimiter.acquire() 方法会阻塞当前线程直到获取到许可，确保调用 doSomeLimitedOperation() 操作的频率不会超过限制。

RateLimiter 还提供了其他的方法，例如tryAcquire()，它会尝试获取许可而不会阻塞，立即返回获取成功或失败的结果。还可以设置等待时间上限，比如 tryAcquire(long timeout, TimeUnit unit) 可以设置最大等待时间。

Guava的RateLimiter非常灵活，它支持平滑突发限制（SmoothBursty）和平滑预热限制（SmoothWarmingUp）等多种模式，可以根据特定的应用场景来选择合适的限流策略。

3.2 sentinel（单机或者分布式）

Sentinel是阿里巴巴开源的一款面向分布式系统的流量控制和熔断降级组件。它提供了实时的流量控制、熔断降级、系统负载保护和实时监控等功能，可以帮助开发者保护系统的稳定性和可靠性。

单机模式

• DefaultController：是一个非常典型的滑动窗口计数器算法实现，将当前统计的qps和请求进来的qps进行求和，小于限流值则通过，大于则计算一个等待时间，稍后再试；
• ThrottlingController：是漏斗算法的实现，实现思路已经在源码片段中加了备注；
• WarmUpController：实现参考了Guava的带预热的RateLimiter，区别是Guava侧重于请求间隔，类似前面提到的令牌桶，而Sentinel更关注于请求数，和令牌桶算法有点类似；
• WarmUpRateLimiterController：低水位使用预热算法，高水位使用滑动窗口计数器算法排队。

集群模式

Sentinel 集群限流服务端有两种启动方式：

• 嵌入模式（Embedded）适合应用级别的限流，部署简单，但对应用性能有影响
• 独立模式（Alone）适合全局限流，需要独立部署

用法

Sentinel的用法主要包括以下几个方面：

（1）引入依赖：在项目中引入Sentinel的相关依赖，可以使用Maven或Gradle进行依赖管理。例如，在Maven项目的pom.xml文件中添加以下依赖：

<dependency><groupId>com.alibaba.csp</groupId><artifactId>sentinel-core</artifactId><version>1.8.2</version>
</dependency>

（2）配置规则：根据实际需求，配置Sentinel的流量控制规则、熔断降级规则等。可以通过编程方式或配置文件方式进行规则的配置。例如，可以在启动类中使用注解方式配置流量控制规则：

@SentinelResource(value = "demo", blockHandler = "handleBlock")
public String demo() {// ...
}

（3）启动Agent：在应用启动时，启动Sentinel的Agent，开启对系统的流量控制和熔断降级功能的保护。可以通过命令行启动Agent，或者在代码中进行启动。例如，在Spring Boot的启动类中添加如下代码：

public static void main(String[] args) {System.setProperty("csp.sentinel.dashboard.server", "localhost:8080"); // 设置控制台地址System.setProperty("project.name", "your-project-name"); // 设置应用名称com.alibaba.csp.sentinel.init.InitExecutor.doInit();SpringApplication.run(YourApplication.class, args);
}

（4）监控和管理：使用Sentinel的控制台进行实时监控、配置管理等操作。可以通过浏览器访问Sentinel的控制台界面，查看系统的运行情况和流量控制情况。通过控制台，可以对规则进行动态修改，查看监控数据和告警信息。

3.3 Nginx（分布式）

Nginx从网关这一层面考虑，可以作为最前置的网关，抵挡大部分的网络流量，因此使用Nginx进行限流也是一个很好的选择，在Nginx中，也提供了常用的基于限流相关的策略配置。

用法

Nginx 提供了两种限流方法：一种是控制速率，另一种是控制并发连接数。

控制速率

我们需要使用 limit_req_zone 用来限制单位时间内的请求数，即速率限制，因为Nginx的限流统计是基于毫秒的，我们设置的速度是 2r/s，转换一下就是500毫秒内单个IP只允许通过1个请求，从501ms开始才允许通过第2个请求。

控制速率优化版

上面的速率控制虽然很精准但是在生产环境未免太苛刻了，实际情况下我们应该控制一个IP单位总时间内的总访问次数，而不是像上面那样精确到毫秒，我们可以使用 burst 关键字开启此设置。

burst=4意思是每个IP最多允许4个突发请求

控制并发数

利用 limit_conn_zone 和 limit_conn 两个指令即可控制并发数

其中 limit_conn perip 10 表示限制单个 IP 同时最多能持有 10 个连接；limit_conn perserver 100 表示 server 同时能处理并发连接的总数为 100 个。

注意：只有当 request header 被后端处理后，这个连接才进行计数。

四、小结

算法	简介	核心思想	优点	缺点	开源工具/中间件	适用业务场景
固定窗口限流	在固定的时间窗口内计数请求，达到阈值则限流。	将时间分割成固定大小的窗口，每个窗口内独立计数。	实现简单，性能较好。	可能会有时间窗口切换时的突发流量。	Nginx、Apache、RateLimiter (Guava)	需要简单限流，对流量突增不敏感的场景。 eg: 电商平台在每日定时秒杀活动开始时，用于防止瞬时高流量冲垮系统。
滑动窗口限流	在滑动的时间窗口内计数请求，达到阈值则限流。	将时间分割为多个小窗口，统计近期内的总请求数。	平滑请求，避免固定窗口算法中的突发流量。	实现比固定窗口复杂，消耗资源较多。	Redis、Sentinel	对流量平滑性有较高要求的场景。  eg: 社交媒体平台的消息发送功能，用于平滑处理高峰期的消息发送请求，避免服务短暂的超负荷。
令牌桶限流	以恒定速率向桶中添加令牌，请求消耗令牌，无令牌时限流。	以一定速率生成令牌，请求必须拥有令牌才能执行。	允许一定程度的突发流量，平滑处理请求。	对突发流量的容忍可能导致短时间内资源过载。	Guava、Nginx、Apache、 Sentinel	对突发流量有一定要求，且需要一定程度的平滑处理的场景。  eg: 视频流媒体服务，允许用户在网络状况良好时快速缓冲视频，同时在网络拥堵时平滑地降低请求速率。
漏桶算法	漏桶以固定速率出水，请求以任意速率流入桶内，桶满则溢出（限流）。	以恒定的速率处理请求，超过该速率的请求被限制。	输出流量稳定，能够限制流量的最大速率。	无法应对突发流量，可能导致请求等待时间过长。	Apache、Nginx	适用于需要严格控制处理速率，对请求响应时间要求不高的场景。  eg: API网关对外提供服务的接口，需要确保后端服务的调用速率不超过其最大处理能力，防止服务崩溃
滑动日志限流	使用滑动时间窗口记录请求日志，通过日志来判断是否超出速率限制。	记录最近一段时间内的请求日志，实时判断请求是否超限。	能够更细粒度地控制请求速率，比固定窗口更公平。	实现复杂，存储和计算请求日志成本较高。	-	对实时性要求高，且需要精确控制请求速率的高级限流场景。  eg： 高频交易系统，需要根据实时交易数据精确控制交易请求速率，防止因超负荷而影响整体市场的稳定性。