一、引言：限流在高并发系统中的核心价值

二、固定窗口限流算法：简单直观的流量控制

2.1 算法原理：时间分段与计数限制

• 将时间划分为若干个长度相等的“窗口”（如 1 秒、1 分钟等）；

• 每个窗口内维护一个请求计数器，记录当前窗口内收到的请求数量；

• 当请求到来时，先判断当前窗口的计数器是否已达到预设阈值：若未达到，则计数器加 1 并允许请求通过；若已达到，则拒绝请求；

• 当当前窗口结束，计数器自动重置为 0，新窗口开始后重新计数。

2.2 数学公式表达：计数器的状态流转

• \( T \)：固定窗口的时间长度（单位：秒）；

• \( N \)：每个窗口内的最大请求数（限流阈值）；

• \( count \)：当前窗口内的请求计数器（初始值为 0）；

• \( t \)：当前请求的时间相对于窗口开始时间的偏移量（\( 0 \leq t < T \)）。

1. 当新请求到来时（时间偏移为 \( t \)），首先更新计数器： \[ count = count + 1 \]

2. 判断计数器是否超过阈值：
• 若 \( count > N \)：拒绝请求；
• 若 \( count \leq N \)：允许请求；

3. 当窗口结束时（\( t = T \)），重置计数器： \[ count = 0 \]

2.3 基于 Guava 的代码实现：模拟固定窗口效果

• 通过 RateLimiter.create(5.0) 创建一个每秒生成 5 个令牌的限流器，模拟“1 秒窗口内允许 5 个请求”的固定窗口效果；

• tryAcquire(1, 0, TimeUnit.MILLISECONDS) 尝试获取 1 个令牌，超时时间为 0（即不等待），获取成功则请求通过，否则被限流；

• 前 15 个请求间隔 50ms 发送，1 秒内会产生 20 个请求，超过阈值 5，因此大部分请求被限流；

• 等待 1 秒后，窗口重置，后续请求可正常通过。

2.4 优缺点分析：简单性与临界问题的博弈

优点：

1. 实现简单，易于理解
固定窗口算法仅需维护一个计数器和窗口结束时间，逻辑清晰，无论是手写实现还是使用工具库，都能快速落地。例如，在分布式系统中，可通过 Redis 的 INCR 命令和 EXPIRE 命令轻松实现：

2. 资源消耗极低
无需复杂的数据结构（如队列、滑动窗口数组），仅需存储计数器和窗口时间，内存占用和计算开销均可忽略不计，适合资源受限的场景（如嵌入式设备、低配置服务器）。

缺点：

1. 临界问题：窗口切换时的流量突增
这是固定窗口算法最致命的缺陷。假设窗口长度为 1 秒，阈值为 100 次请求：
• 在第 1 秒的最后 100ms 内，突然涌入 100 次请求，全部通过（计数器从 0 增至 100）；
• 第 2 秒的前 100ms 内，又涌入 100 次请求，由于新窗口计数器重置为 0，这 100 次请求也全部通过；
• 结果：在 200ms 内，系统实际处理了 200 次请求，远超“每秒 100 次”的限制，可能导致系统过载。
图示描述（模拟临界问题）：

2. 限流精度低，流量控制粗糙
固定窗口只能在窗口结束时重置计数器，无法对窗口内的流量分布进行调控。例如，若窗口内前 10% 的时间就用完了所有配额，剩余 90% 的时间内所有请求都会被拒绝，可能导致用户体验不佳（如“秒杀活动开始 10 秒就提示‘活动结束’”）。

2.5 适用场景：简单场景的快速限流

1. 小型应用或内部系统限流
对于用户量少、流量稳定的内部管理系统（如后台 CMS、员工打卡系统），固定窗口的简单性足以满足需求，无需引入复杂算法。例如，限制“单个用户每分钟最多查询 100 次数据”，即使存在临界问题，也不会对系统造成致命影响。

2. 测试环境流量模拟
在测试环境中，开发者常需要模拟“每秒 100 次请求”的流量压力，固定窗口算法可快速搭建限流规则，验证系统在阈值附近的表现（如是否返回正确的限流提示、是否触发降级策略）。

3. 粗粒度限流兜底
在多层限流架构中，固定窗口可作为“第一层兜底限流”，过滤掉明显超出系统承载能力的流量（如“每秒超过 10000 次请求直接拒绝”），减轻后续精细限流的压力。

三、滑动窗口限流算法：更精细的流量控制

3.1 算法原理：窗口细分与动态滑动

• 固定窗口是“非连续”的，窗口结束后计数器直接重置；

• 滑动窗口是“连续”的，通过子窗口的动态更新实现流量的平滑控制。

• 初始时，滑动窗口覆盖子窗口 1-5（0-10 秒）；

• 当时间到达 2 秒时，窗口滑动：淘汰子窗口 1（0-2 秒），纳入子窗口 6（10-12 秒），此时滑动窗口覆盖子窗口 2-6（2-12 秒）；

• 每次请求到来时，计算当前滑动窗口内 5 个子窗口的总请求数，若超过 10 则限流。

3.2 数学公式表达：子窗口的动态更新与计数

• \( T \)：滑动窗口总时间长度（单位：秒）；

• \( n \)：子窗口数量（\( n \geq 1 \)）；

• \( t = T/n \)：每个子窗口的时间长度（单位：秒）；

• \( N \)：滑动窗口内的最大请求数（限流阈值）；

• \( count_i \)：第 \( i \) 个子窗口的请求计数器（\( i = 1, 2, ..., n \)，初始值为 0）；

• \( currentTime \)：当前请求的时间戳；

• \( windowStartTime \)：当前滑动窗口的起始时间戳。

1. 窗口滑动判断：计算当前时间与窗口起始时间的差值 \( \Delta = currentTime - windowStartTime \)，确定需要淘汰的子窗口数量 \( k = \lfloor \Delta / t \rfloor \)。若 \( k > 0 \)，则淘汰最旧的 \( k \) 个子窗口（计数器重置为 0），并更新窗口起始时间：
\[ windowStartTime = windowStartTime + k \times t \]

2. 子窗口定位：确定当前请求所属的子窗口索引 \( m \)：
\[ m = \lfloor (currentTime - windowStartTime) / t \rfloor + 1 \]

3. 计数与限流判断：更新子窗口计数器，并计算总请求数：
\[ count_m = count_m + 1 \]
\[ totalCount = \sum_{i=1}^{n} count_i \]
• 若 \( totalCount > N \)：拒绝请求；
• 若 \( totalCount \leq N \)：允许请求。

3.3 基于 Guava 的代码实现：手动维护滑动窗口

• 构造函数中初始化总窗口长度、子窗口数量和限流阈值，子窗口计数器列表初始化为全 0；

• tryAcquire() 方法中，先根据时间差计算需要滑动的子窗口数量，淘汰旧窗口并新增空窗口；

• 定位当前请求所属的子窗口，更新计数器后计算总请求数，判断是否允许通过；

• 临界场景测试中，前 2 秒发送 10 次请求（填满第一个子窗口），等待 2 秒后窗口滑动，旧子窗口被淘汰，新请求可继续通过，避免了固定窗口的临界问题。

3.4 优缺点分析：精度提升与成本增加的平衡

优点：

1. 解决临界问题，限流更平滑
滑动窗口通过细分窗口和动态滑动，确保任意时间段内的请求数不会超过阈值。例如，在 10 秒窗口、阈值 100 次的场景下，无论请求在窗口内如何分布，任意连续 10 秒的总请求数都不会超过 100，避免了固定窗口中“200 次请求在 2 秒内通过”的极端情况。

2. 精度可控，灵活性高
限流精度可通过调整子窗口数量控制：子窗口数量越多（即单个子窗口越小），限流精度越高。例如，1 分钟窗口分为 60 个 1 秒子窗口，可精确控制每秒的流量波动；若分为 6 个 10 秒子窗口，则精度稍低但性能更好。开发者可根据业务需求在精度和性能间权衡。

缺点：

1. 实现复杂度高于固定窗口
需维护多个子窗口的计数器，处理窗口滑动逻辑（淘汰旧窗口、新增新窗口），代码逻辑比固定窗口更复杂。尤其是在分布式场景中，需通过分布式缓存（如 Redis 的 ZSet）存储子窗口数据，实现难度更高。

2. 资源消耗随子窗口数量增加而上升
子窗口数量越多，需要存储的计数器数据越多，计算总请求数时的遍历开销也越大。例如，1 分钟窗口分为 60 个子窗口，每次请求都需遍历 60 个计数器求和，而固定窗口只需操作 1 个计数器。在高并发场景下，这可能成为性能瓶颈。

3.5 适用场景：流量波动大且精度要求高的场景

1. 电商秒杀与促销活动
秒杀活动中流量波动极大（可能在几秒内从 0 飙升至每秒数万次），固定窗口的临界问题可能导致系统瞬间过载。滑动窗口可通过细分窗口（如 1 秒窗口分为 10 个 100ms 子窗口），精确控制每秒的请求量，避免流量突增。例如，某电商平台在秒杀活动中设置“1 秒内最多 1000 次请求”，并分为 10 个子窗口，确保每 100ms 最多通过 100 次请求，平滑流量峰值。

2. API 接口的精细限流
对于核心业务 API（如支付接口、订单提交接口），需严格控制流量以保障稳定性。滑动窗口可实现“每分钟最多 1000 次调用”的精细控制，且避免临界问题导致的接口过载。例如，支付接口若使用固定窗口，可能在窗口切换时瞬间收到 2000 次请求，而滑动窗口可将其分散到多个子窗口中，确保总请求数不超限。

3. 金融交易系统
金融系统对稳定性和准确性要求极高，流量波动可能引发交易失败或数据不一致。滑动窗口可精确控制每秒的交易请求数，例如“每秒最多 500 笔交易”，通过 10 个子窗口（每 100ms 一个）确保交易均匀处理，降低系统压力。

四、漏桶限流算法：平滑输出的流量“稳压器”

4.1 算法原理：水滴入桶与匀速流出

• 漏桶：具有固定容量，用于暂存待处理的请求；

• 注水口：接收外部请求，将请求放入漏桶；

• 漏水口：以固定速率从漏桶中取出请求并处理（漏水速率 = 系统处理速率）。

• 若请求以 1 个/秒的速率到来：漏桶不会满，所有请求被立即处理，输出速率稳定为 1 个/秒；

• 若请求以 5 个/秒的速率突发到来：前 2 秒内漏桶会积累 \( (5-2) \times 2 = 6 \) 个请求（未超过容量 10），第 3 秒继续注入 5 个，漏桶累计 6 + (5-2) = 9 个；若第 4 秒仍以 5 个/秒注入，漏桶将满（9 + 5 - 2 = 12 > 10），超出的 2 个请求被丢弃；

• 突发结束后，漏桶中的请求会以 2 个/秒的速率逐渐处理完毕，输出速率始终稳定。

4.2 数学公式表达：水量（请求数）的动态平衡

• \( C \)：漏桶容量（最大可容纳的请求数）；

• \( r \)：漏水速率（单位：请求/秒，即系统处理速率）；

• \( waterLevel \)：当前漏桶中的请求数（水量，初始值 0）；

• \( lastLeakTime \)：上次漏水的时间戳；

• \( currentTime \)：当前请求的时间戳。

1. 计算漏水总量：请求到来时，先计算从上次漏水到当前的时间差 \( \Delta t = currentTime - lastLeakTime \)，这段时间内漏出的水量为：
\[ leaked = r \times \Delta t \]
更新当前水量（不低于 0）：
\[ waterLevel = \max(0, waterLevel - leaked) \]
更新上次漏水时间：
\[ lastLeakTime = currentTime \]

2. 处理新请求：尝试将新请求加入漏桶：
• 若 \( waterLevel < C \)：水量加 1，允许请求进入漏桶（等待处理）；
• 若 \( waterLevel \geq C \)：拒绝请求（水量超过容量）。

4.3 基于 Guava 的代码实现：模拟漏桶的注水与漏水

• 漏桶容量为 10，漏水速率为 2 个/秒（即每秒处理 2 个请求）；

• tryAcquire() 方法中，先根据时间差计算漏水总量，更新当前水量，再判断是否可加入新请求；

• 匀速请求测试中，水量始终低于容量，所有请求通过；

• 突发请求测试中，由于注入速率（5 个/秒）高于漏水速率（2 个/秒），水量逐渐增长至容量，超出的请求被限流；

• 静置后，水量随时间减少，新请求可再次通过。

4.4 优缺点分析：稳定性与灵活性的权衡

优点：

1. 输出流量绝对平稳
漏桶算法的核心优势是无论输入流量如何波动，输出速率始终等于漏水速率。这对于需要严格控制处理速率的场景至关重要，例如：
• 网络传输中，避免因数据发送过快导致网络拥塞；
• 数据库访问中，防止瞬间大量查询拖垮数据库，确保每秒查询数稳定。

2. 实现逻辑直观，易于理解
算法原理贴近生活中的物理现象，代码实现只需维护水量、漏水速率和时间戳，逻辑清晰，无需复杂的数据结构。

缺点：

1. 无法应对合理的突发流量
漏桶的漏水速率固定，即使系统有空闲资源，也无法快速处理突发的合理请求。例如，某系统平时流量为 10 个/秒，漏桶速率设为 10 个/秒；若某天突然有 100 个紧急请求（系统实际可处理 50 个/秒），漏桶会因容量限制丢弃大部分请求，导致资源浪费和用户体验下降。

2. 容量参数难以设置
漏桶容量过小，容易在轻微流量波动时触发限流；容量过大，则可能积累过多请求，导致请求处理延迟过高（如请求在桶中等待数秒才被处理）。参数设置需要长期的流量观测和调优，成本较高。

4.5 适用场景：需严格控制输出速率的场景

1. 网络流量控制
在网络传输中，漏桶算法被广泛用于控制数据发送速率，避免单个节点占用过多带宽导致网络拥塞。例如：
• 路由器中，对每个端口设置漏桶限流，确保不同设备的流量公平分配；
• 客户端 SDK 中，控制 API 调用的发送速率，避免因频繁请求被服务端封禁。

2. 数据库访问限流
数据库是系统的核心瓶颈之一，漏桶算法可控制每秒的数据库查询/写入次数，防止瞬间高并发拖垮数据库。例如，某订单系统通过漏桶限制“每秒最多 100 次数据库写入”，确保数据库性能稳定，避免锁竞争和连接耗尽。

3. 第三方 API 调用控制
调用第三方 API 时，通常会有严格的速率限制（如“每分钟最多 60 次调用”）。漏桶算法可模拟第三方的限流逻辑，确保本地调用速率不超限，避免 API 密钥被封禁。例如，调用微信支付 API 时，使用漏桶控制每秒调用次数，匹配微信的限流规则。

五、令牌桶限流算法：支持突发的灵活限流

5.1 算法原理：令牌生成与请求获取

• 漏桶控制“输出速率”，令牌桶控制“输入速率”但允许突发（桶中积累的令牌可应对突发流量）；

• 漏桶的请求处理延迟可能很高（请求在桶中排队），令牌桶的请求要么立即通过（获取令牌），要么立即被限流（无令牌），延迟更低。

• 令牌桶：具有固定容量，存储待分配的令牌；

• 令牌生成器：以固定速率向桶中添加令牌（如每秒生成 10 个令牌）；

• 请求处理器：请求需获取令牌才能被处理，无令牌则被拒绝。

• 系统空闲时，令牌桶会被填满（10 个令牌）；

• 若突然有 10 个请求到来，可一次性获取所有令牌，全部通过（支持突发）；

• 之后，令牌以 2 个/秒的速率生成，后续请求需等待令牌生成（如第 11 个请求需等待 0.5 秒获取令牌）；

• 若请求速率长期超过生成速率（如 5 个/秒），令牌桶会被耗尽，超出的请求被限流，最终通过速率稳定为 2 个/秒。

5.2 数学公式表达：令牌的动态生成与消耗

• \( C \)：令牌桶容量（最大令牌数）；

• \( r \)：令牌生成速率（单位：令牌/秒）；

• \( tokenCount \)：当前桶中的令牌数（初始值为 \( C \)，即桶满）；

• \( lastGenerateTime \)：上次生成令牌的时间戳；

• \( currentTime \)：当前请求的时间戳。

1. 生成新令牌：请求到来时，先计算从上次生成令牌到当前的时间差 \( \Delta t = currentTime - lastGenerateTime \)，这段时间内生成的令牌数为：
\[ generated = r \times \Delta t \]
更新当前令牌数（不超过桶容量）：
\[ tokenCount = \min(C, tokenCount + generated) \]
更新上次生成时间：
\[ lastGenerateTime = currentTime \]

2. 处理请求：尝试获取令牌：
• 若 \( tokenCount > 0 \)：令牌数减 1，允许请求通过；
• 若 \( tokenCount = 0 \)：拒绝请求（无令牌可用）。

5.3 基于 Guava 的代码实现：RateLimiter 的使用与原理

5.3.1 Guava RateLimiter 基础使用

• RateLimiter.create(2.0) 创建一个每秒生成 2 个令牌的限流器，初始时令牌桶是满的（容量约为 2 * 10 = 20 个，Guava 会动态调整容量）；

• acquire() 方法阻塞等待获取 1 个令牌，返回等待时间（秒）；availablePermits() 方法返回当前可用令牌数估计值；

• 突发流量测试中，前 5 个请求无需等待（桶中有足够令牌）；

• 持续高流量测试中，令牌被耗尽，请求需等待令牌生成（等待时间约为 0.5 秒/个，匹配生成速率）；

• 系统空闲后，令牌桶重新填满，可再次应对突发流量。

5.3.2 Guava RateLimiter 的核心原理

1. 令牌生成机制：
不实时生成令牌，而是在请求到来时“惰性计算”令牌数——根据上次请求时间和当前时间的差值，一次性计算这段时间内应生成的令牌，更新令牌桶数量。这种“惰性计算”减少了定时任务的开销，提高性能。

2. 平滑突发与预热机制：
Guava 提供两种限流器：
• SmoothBursty：支持突发流量（默认实现），令牌桶容量为 rate * 10，允许短时间内消耗所有积累的令牌；
• SmoothWarmingUp：支持预热机制，令牌生成速率从低到高逐渐达到目标速率（适用于需要“预热”的系统，如缓存服务启动初期）。

3. 非阻塞与阻塞 API：
• tryAcquire()：非阻塞获取令牌，超时返回 false；
• acquire()：阻塞等待获取令牌，确保请求最终通过（但可能等待较长时间）。

5.4 优缺点分析：灵活性与复杂性的平衡

优点：

1. 支持合理的突发流量
令牌桶可积累令牌，当系统空闲时，桶中会存储大量令牌；当突发流量到来时，可一次性消耗积累的令牌，快速处理请求。这解决了漏桶算法无法应对突发的问题，同时避免了固定窗口的临界问题。例如，某系统平时流量为 10 个/秒，令牌桶容量为 100 个，若突然有 100 个紧急请求，可全部通过（消耗所有令牌），之后恢复正常速率处理，充分利用系统空闲资源。

2. 长期速率可控，短期灵活
令牌桶的长期请求通过速率等于令牌生成速率（如每秒 10 个），确保系统不会长期过载；同时，短期可通过积累的令牌应对流量峰值，兼顾稳定性和灵活性。

3. 实现高效，适用场景广
Guava 的 RateLimiter 采用惰性计算和高效的数据结构，性能优异，可支持高并发场景（每秒数万次请求）。API 简洁易用，开发者无需关心底层细节，即可快速集成。

缺点：

1. 实现复杂度高于固定窗口和漏桶
令牌桶需要维护令牌生成速率、令牌桶容量、上次请求时间等状态，逻辑比固定窗口复杂；尤其是分布式场景下，需解决令牌桶状态同步问题（如使用 Redis 实现分布式令牌桶），实现难度较高。

2. 参数调优难度大
令牌生成速率和桶容量需根据业务场景精准设置：
• 速率过高，无法起到限流作用；速率过低，会影响正常请求；
• 容量过大，可能导致突发流量过多，系统瞬间过载；容量过小，则无法应对合理突发。需通过长期的流量监控和压测确定最优参数。

3. 分布式场景挑战大
单机令牌桶易实现，但分布式系统中，多个节点需共享令牌桶状态，否则可能出现“每个节点都允许 100 个请求，总流量超过阈值”的问题。分布式令牌桶需依赖 Redis 等中间件，存在网络延迟和一致性问题。

5.5 适用场景：需兼顾灵活性与稳定性的场景

1. API 网关限流
API 网关是所有请求的入口，需应对各种流量模式（平稳流量、突发流量、恶意攻击）。令牌桶算法可在网关层实现全局限流，例如：
• 对普通用户设置“每秒 10 个令牌”，桶容量 100（允许偶尔突发）；
• 对 VIP 用户设置“每秒 50 个令牌”，桶容量 500（更高的突发容忍度）；
• 结合黑白名单，对恶意 IP 限制令牌生成速率为 0，直接封禁。

2. 微服务间调用限流
在微服务架构中，服务间依赖复杂，一个服务过载可能引发“雪崩效应”。令牌桶可控制服务的调用速率，例如：
• 订单服务调用库存服务时，设置“每秒 100 个令牌”，防止库存服务被压垮；
• 当库存服务返回“繁忙”时，动态降低令牌生成速率，实现自适应限流。

3. 用户行为限流
对用户的高频操作（如登录、搜索、评论）进行限流，防止恶意行为（如暴力破解、刷评论）。令牌桶可根据用户等级设置差异化策略：
• 普通用户：“每分钟 60 个搜索令牌”，桶容量 10；
• 会员用户：“每分钟 300 个搜索令牌”，桶容量 50，提升高价值用户体验。

六、四种限流算法的对比与实践指南

6.1 算法核心特性对比

6.2 算法选择决策指南

1. 明确限流目标：
• 若目标是“防止长期过载”（如控制每秒请求数不超过系统承载能力），优先选择令牌桶或滑动窗口；
• 若目标是“严格控制输出速率”（如网络带宽限制），选择漏桶；
• 若目标是“简单兜底限流”，选择固定窗口。

2. 分析流量特点：
• 流量平稳且无突发：固定窗口、滑动窗口、令牌桶均可；
• 流量波动大且有合理突发：必须选择令牌桶；
• 流量突发但需严格匀速处理：选择漏桶。

3. 评估系统资源与复杂度：
• 资源受限（如嵌入式设备）：选择固定窗口；
• 高并发且需精度：选择滑动窗口或令牌桶（优先 Guava 令牌桶）；
• 分布式场景：固定窗口（Redis 实现）或分布式令牌桶（如 Redis + Lua）。

4. 参考行业最佳实践：
• API 网关：令牌桶（支持突发 + 灵活）；
• 数据库访问：漏桶（严格控制写入速率）或令牌桶；
• 秒杀活动：滑动窗口（精度高）+ 令牌桶（应对突发）；
• 第三方 API 调用：漏桶（匹配第三方速率限制）。

6.3 实践中的限流架构设计

1. 接入层限流：
• 位置：CDN、负载均衡器（如 Nginx）；
• 算法：固定窗口（粗粒度兜底）；
• 目标：过滤恶意流量和明显过载的流量（如每秒超过 10 万次请求）。

2. 网关层限流：
• 位置：API 网关（如 Spring Cloud Gateway、Kong）；
• 算法：令牌桶（支持突发）+ 滑动窗口（精细控制）；
• 目标：按接口、用户、IP 等维度限流，例如“用户 A 每分钟最多调用支付接口 100 次”。

3. 应用层限流：
• 位置：服务内部（如 Spring Boot 应用）；
• 算法：令牌桶（Guava RateLimiter）；
• 目标：保护服务自身的核心资源（如线程池、数据库连接），例如“每秒最多处理 1000 个订单创建请求”。

4. 数据层限流：
• 位置：数据库、缓存；
• 算法：漏桶（控制读写速率）；
• 目标：防止数据库/缓存被高并发压垮，例如“Redis 每秒最多 5000 次写入”。

6.4 限流效果监控与调优

1. 关键监控指标：
• 通过率：通过请求数 / 总请求数（过低说明限流过严，过高说明限流不足）；
• 限流次数：单位时间内被限流的请求数（突增可能预示异常流量）；
• 响应延迟：请求从到达至处理完成的时间（延迟过高可能因限流参数不合理）。

2. 动态调优策略：
• 流量低谷时：适当提高令牌生成速率或窗口阈值，提高资源利用率；
• 流量高峰时：降低速率或阈值，确保系统稳定；
• 异常流量（如 DDoS 攻击）：临时启用严格限流（如固定窗口阈值降至 10 次/秒）。

3. 降级与熔断结合：
限流是“被动防御”，需与降级、熔断结合形成完整的容错体系：
• 限流触发时，返回友好的降级提示（如“当前请求过多，请稍后再试”）；
• 若限流频繁触发，触发熔断机制（如暂停非核心功能），释放系统资源。

七、总结与展望

• 固定窗口：简单直观，适合粗粒度兜底限流，但存在临界问题；

• 滑动窗口：通过细分窗口解决临界问题，精度高，适合流量波动场景；

• 漏桶：严格控制输出速率，适合网络传输和数据库访问等刚性场景；

• 令牌桶：支持突发流量，兼顾灵活性和稳定性，是大多数场景的首选。