限流（Rate Limiting）是保障系统稳定性和服务质量的关键机制，尤其在高并发、突发流量、攻击防护等场景中至关重要。

本文将详细介绍四种主流限流算法：

固定窗口（Fixed Window）
滑动窗口（Sliding Window）
令牌桶（Token Bucket）
漏桶算法（Leaky Bucket）

我们将从原理、实现方式、优缺点和适用场景四个维度进行深入分析和对比。

一、固定窗口（Fixed Window）

原理：将时间划分为固定长度窗口，统计每个窗口内的请求数，超过上限则拒绝。

实现方式（常用 Redis INCR + EXPIRE）：

key = f"req:{user_id}:{current_minute}"
count = redis.incr(key)
if count == 1:redis.expire(key, 60)
if count > threshold:reject()

优点：

实现简单，性能高。
Redis 支持天然适配。

缺点：

临界突刺问题：在两个窗口交界点，可能放行两倍请求。

适用场景：

精度要求不高的接口。
管控类后台系统。

二、滑动窗口（Sliding Window）

1. 滑动日志（Sliding Log）

原理：记录每次请求时间戳，实时清理超出时间窗口的旧请求，判断窗口内数量。

优点：

流量限制更精确。
避免突刺。

缺点：

需要维护时间戳列表，内存消耗较大。

2. 滑动窗口计数器（Sliding Window Counter）

原理：将一个窗口拆分为多个小窗口，每个子窗口统计请求数，根据时间加权合并。

优点：

性能和精度之间较好平衡。

适用场景：

高并发、登录、敏感操作等流控要求较高的业务。

三、令牌桶算法（Token Bucket）

原理：

系统以固定速率放入“令牌”到桶中；
每次请求需要“取一个令牌”才能通过；
桶容量有限，超过上限的令牌被丢弃；
若桶为空，请求被限流（或排队等）。

示意图：

+----------+
| 令牌桶    |
|          |<-- 固定速率生成令牌
|   [ ]    |
+----------+↓请求来取令牌 -> 成功 or 被限流

优点：

支持突发流量（令牌可积累）。
灵活控制平均速率与突发能力。
Guava / Nginx 都有成熟实现。

缺点：

实现较复杂。
依赖精准时间调度。

适用场景：

接口限频，突发高并发业务。
LLM API 限流 / OpenAI、Stripe 等系统。

四、漏桶算法（Leaky Bucket）

原理：

所有请求先进入一个桶中；
桶以固定速率“漏水”处理请求；
桶满时，新请求要么被丢弃，要么排队等待。

示意图：

请求 → 桶（队列） → 以恒定速率处理（漏水）↑桶满则拒绝或排队

实现方式：

可以用一个队列存储请求；
后台定期以固定速率出队并处理请求。

优点：

平滑处理请求流量，保持处理速率稳定。
防止服务被瞬时流量压垮。

缺点：

不支持突发流量（桶中积压，排队延迟）。
实现复杂度略高于令牌桶。

适用场景：

网关、负载均衡器的请求调度。
强调处理速率恒定的后台任务系统。

五、算法对比总结

特性	固定窗口	滑动窗口	令牌桶	漏桶
实现复杂度	⭐（简单）	⭐⭐（中等）	⭐⭐⭐（中高）	⭐⭐（中等）
限流精度	低	高	中等	高
是否支持突发请求	否	否	✅	❌
是否平滑	❌	✅	✅	✅
是否常用	✅（Redis）	✅（Sentinel）	✅（Guava、Nginx）	✅（调度系统）