三者均为流量控制（限流）的核心算法，核心目标是保护系统/下游服务不被过载请求击垮，但设计逻辑、适用场景差异显著，具体差异可从核心原理、关键特性、优劣势、适用场景四个维度对比：
一、核心原理（底层逻辑）
| 算法 | 核心原理 | 关键参数举例 |
|---|---|---|
| 滑动窗口 | 将时间切分为“小窗口”（如10秒总窗口拆为10个1秒小窗口），任意连续N个小窗口的请求总量不超过阈值，且窗口随时间“滑动”（每秒剔除最旧1秒数据、加入最新1秒数据），避免固定窗口的“边界峰值”问题。 | 总窗口时长（10秒）、总请求阈值（100个）、小窗口粒度（1秒） |
| 令牌桶 | 系统按固定速率（如10个/秒）向“令牌桶”中生成令牌，请求需先获取令牌才能被处理；桶有最大容量（如100个），令牌满时多余令牌丢弃；空闲时桶内可积累令牌，突发请求可消耗积累的令牌。 | 令牌生成速率（10个/秒）、令牌桶容量（100个） |
| 漏斗 | 把请求比作“水流”，系统比作“漏斗”：请求进入漏斗后，必须按固定速率从漏斗底部流出（处理），漏斗有最大容量（如100个），请求满时多余请求直接丢弃；无论输入流量是否突发，输出速率始终严格固定。 | 漏斗流出速率（10个/秒）、漏斗最大容量（100个） |
二、关键特性对比（核心差异点）
| 特性维度 | 滑动窗口 | 令牌桶 | 漏斗 |
|---|---|---|---|
| 1. 突发流量处理 | 允许“窗口内突发”：只要请求总量不超窗口阈值，可集中在窗口内某一刻处理（如10秒窗口的100个请求，可集中在最后1秒处理）；无法利用历史空闲资源（前9秒空闲，不影响最后1秒的请求上限）。 | 允许“可控突发”：可消耗空闲时积累的令牌（如桶满100个令牌，可一次性处理100个突发请求）；突发规模有上限（=桶容量），超容量的突发请求会被限流。 | 完全禁止突发：无论输入是否突发（如瞬间1000个请求），输出速率严格等于配置速率（如10个/秒）；请求需排队等待，本质是“削峰填谷”。 |
| 2. 流量平滑效果 | 相对平滑：仅解决“固定窗口边界峰值”问题（如避免“前1秒最后100ms+后1秒前100ms”的双倍请求），但窗口内仍可能有集中请求（如1秒小窗口内10个请求集中在100ms处理）。 | 动态平滑：无突发时，输出速率≈令牌生成速率（平滑）；有突发时，输出速率=生成速率+桶内积累令牌（可控波动），整体仍保持“不超上限”的平滑。 | 绝对平滑：输出速率严格等于配置的“流出速率”（如每个请求间隔100ms），从根源上避免流量波动，是三者中平滑度最高的。 |
| 3. 资源利用效率 | 中等：仅限制“单位时间总量”，未利用历史空闲资源（前9秒空闲，额度无法转移到最后1秒）。 | 高：空闲时积累令牌，突发时消耗令牌，充分利用系统空闲资源应对峰值，兼顾灵活性与稳定性。 | 低：无论系统是否空闲，都强制按固定速率处理，空闲资源无法利用，突发请求需排队，可能导致响应延迟增加。 |
三、优劣势总结
| 算法 | 优势 | 劣势 |
|---|---|---|
| 滑动窗口 | 1. 精细化控制单位时间请求总量，易理解； 2. 避免固定窗口的边界峰值问题。 |
1. 无法利用历史空闲资源，突发能力弱； 2. 窗口粒度需权衡（粒度太粗仍有波动，太细耗性能）。 |
| 令牌桶 | 1. 支持可控突发，兼顾灵活性与稳定性； 2. 空闲时积累令牌，资源利用率高。 |
1. 突发规模依赖桶容量，配置不当可能过载； 2. 实现略复杂（需维护令牌生成与消耗逻辑）。 |
| 漏斗 | 1. 绝对平滑，严格保护下游服务； 2. 逻辑简单，易实现（排队+固定速率输出）。 |
1. 禁止任何突发，资源利用率低； 2. 突发请求会排队，响应延迟高。 |
四、适用场景（选型关键）
| 算法 | 典型场景 |
|---|---|
| 滑动窗口 | 1. 控制API接口的“单位时间请求总量”（如1分钟最多1000次调用）； 2. 避免固定窗口的边界峰值，适合对“总量”敏感、对“瞬时速率”要求不极致的场景。 |
| 令牌桶 | 1. 需应对突发流量的场景（如电商促销瞬间流量、用户登录峰值）； 2. 带宽控制（如服务器出口带宽限制，允许短时间超速率，避免空闲带宽浪费）。 |
| 漏斗 | 1. 调用第三方API（第三方严格限制每秒调用次数，需绝对匀速避免被封禁）； 2. 数据库写入（避免突发写入压垮数据库，需严格控制写入速率）。 |
五、一句话总结
- 滑动窗口：管总量，防边界峰值，适合对“单位时间请求数”有明确限制的场景；
- 令牌桶：保灵活，允可控突发，适合需利用空闲资源应对峰值的场景；
- 漏斗：强平滑，禁任何突发，适合需严格保护下游、不允许流量波动的场景。
