速率限制模式

算法

固定窗口问题： 用户在11:59发送完整限额请求，又在12:01再次发送，导致有效速率翻倍。滑动窗口可解决此问题。

令牌桶

桶内最多容纳一定数量的令牌。令牌以固定速率补充。每个请求消耗一个令牌。

python
class TokenBucket:
def init(self, capacity: int, refill_rate: float):
self.capacity = capacity
self.tokens = capacity
self.refillrate = refillrate # 每秒令牌数
self.last_refill = time.monotonic()

def allow(self) -> bool:
now = time.monotonic()
elapsed = now - self.last_refill
self.tokens = min(self.capacity, self.tokens + elapsed * self.refill_rate)
self.last_refill = now
if self.tokens >= 1:
self.tokens -= 1
return True
return False

滑动窗口计数器

固定窗口和滑动窗口日志的混合方案——根据重叠百分比对前一个窗口的计数进行加权：

python
def slidingwindowallow(key: str, limit: int, window_sec: int) -> bool:
now = time.time()
currentwindow = int(now // windowsec)
positioninwindow = (now % windowsec) / windowsec

prevcount = getcount(key, current_window - 1)
currcount = getcount(key, current_window)

estimated = prevcount * (1 - positioninwindow) + currcount
if estimated >= limit:
return False
incrementcount(key, currentwindow)
return True

实现方案

使用网关级限制作为外层防御 + 应用级限制实现细粒度控制。

HTTP头部

始终返回速率限制信息，即使请求成功：

RateLimit-Limit: 1000
RateLimit-Remaining: 742
RateLimit-Reset: 1625097600
Retry-After: 30

429响应体

json
{
error: {
code: ratelimitexceeded,
message: 超出速率限制。每小时最多1000次请求。,
retry_after: 30,
limit: 1000,
reset_at: 2025-07-01T12:00:00Z
}
}

切勿对速率限制返回500或503——429才是正确的状态码。

速率限制层级

在多个粒度上应用限制：

分层定价：

从最具体到最不具体进行评估：按端点 > 按用户 > 按IP。

分布式速率限制

基于Redis的模式，实现跨实例的一致限制：

python
def redisratelimit(redis, key: str, limit: int, window: int) -> bool:
pipe = redis.pipeline()
now = time.time()
window_key = frl:{key}:{int(now // window)}
pipe.incr(window_key)
pipe.expire(window_key, window * 2)
results = pipe.execute()
return results[0] <= limit

原子Lua脚本（防止竞态条件）：

lua
local key = KEYS[1]
local limit = tonumber(ARGV[1])
local window = tonumber(ARGV[2])
local current = redis.call(INCR, key)
if current == 1 then
redis.call(EXPIRE, key, window)
end
return current <= limit and 1 or 0

切勿先执行GET再执行SET——间隔会导致计数溢出。

API网关配置

NGINX：

nginx
http {
limitreqzone $binaryremoteaddr zone=api:10m rate=10r/s;
server {
location /api/ {
limit_req zone=api burst=20 nodelay;
limitreqstatus 429;
}
}
}

Kong：

yaml
plugins:
- name: rate-limiting
config:
minute: 60
hour: 1000
policy: redis
redis_host: redis.internal

客户端处理

客户端必须优雅地处理429：

typescript
async function fetchWithRetry(url: string, maxRetries = 3): Promise {
for (let attempt = 0; attempt < maxRetries; attempt++) {
const res = await fetch(url);
if (res.status !== 429) return res;

const retryAfter = res.headers.get(Retry-After);
const delay = retryAfter
? parseInt(retryAfter, 10) * 1000
: Math.min(1000 2 * attempt, 30000);
await new Promise(r => setTimeout(r, delay));
}
throw new Error(重试后仍超出速率限制);
}

• - 始终尊重Retry-After（若存在）
• 若不存在，使用带抖动的指数退避
• 对批量操作实现请求排队

监控

跟踪以下指标：

• - 速率限制命中率 — 返回429的请求百分比（持续超过5%则告警）
• 接近限制警告 — 剩余额度低于限制10%的请求
• 最高违规者 — 最频繁触发限制的键/IP
• 限制余量 — 正常流量距离上限的接近程度
• 误报 — 被速率限制的合法用户

反模式

绝对禁止

1. 1. 绝对不要对健康检查端点进行速率限制 — 监控系统会误报
2. 绝对不要仅使用客户端提供的标识符作为速率限制键 — 极易被伪造
3. 速率限制时绝对不要返回200 OK — 客户端必须知道被限流
4. 绝对不要未测量实际流量就设置限制 — 你会阻挡合法用户，或设置过高而无效
5. 绝对不要跨不相关租户共享计数器 — 噪声邻居问题
6. 绝对不要跳过内部API的速率限制 — 行为异常的内部服务可能拖垮