速率限制模式

算法对比

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

令牌桶算法

桶中最多持有指定数量的令牌。令牌以固定速率补充。每次请求消耗一个令牌。

class TokenBucket:
    def __init__(self, capacity: int, refill_rate: float):
        self.capacity = capacity
        self.tokens = capacity
        self.refill_rate = refill_rate  # 每秒补充的令牌数
        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

滑动窗口计数器

结合固定窗口与滑动窗口日志的优点——根据前一窗口的计数按重叠比例加权：

def sliding_window_allow(key: str, limit: int, window_sec: int) -> bool:
    now = time.time()
    current_window = int(now // window_sec)
    position_in_window = (now % window_sec) / window_sec

    prev_count = get_count(key, current_window - 1)
    curr_count = get_count(key, current_window)

    estimated = prev_count * (1 - position_in_window) + curr_count
    if estimated >= limit:
        return False
    increment_count(key, current_window)
    return True

实现方式

建议在网关层设置外层防护，并在应用层实现细粒度控制。

HTTP 响应头

所有响应中均应返回速率限制信息，包括成功请求：

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

429 错误响应体示例

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

速率限制不应返回 500 或 503 错误码，应使用 429 表示请求过多。

速率限制层级

在多个粒度上应用限制策略：

分层定价方案：

评估顺序应从最具体到最不具体：按接口 > 按用户 > 按 IP。

分布式速率限制

基于 Redis 的实现方式，确保跨多个实例的一致性：

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

原子 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

切勿使用先查询再设置的方式——中间间隙可能导致计数超限。

API 网关配置

NGINX:

http {
    limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
    server {
        location /api/ {
            limit_req zone=api burst=20 nodelay;
            limit_req_status 429;
        }
    }
}

Kong:

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

客户端处理

客户端必须妥善处理 429 响应：

async function fetchWithRetry(url: string, maxRetries = 3): Promise<Response> {
  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 头部，必须遵守其值
• 当 Retry-After 缺失时，使用带随机抖动的指数退避
• 批量操作应实现请求队列机制

监控指标

持续跟踪以下关键指标：

• 限流命中率 — 返回 429 状态码的请求占比（持续超过 5% 时触发告警）
• 接近限流警告 — 剩余配额低于限额 10% 的请求
• 主要违规者 — 频繁触发限流的 API 密钥或 IP 地址
• 限流余量 — 正常流量距离上限的距离
• 误触发 — 合法用户被错误地限流

反模式

绝对不要做

1. 绝不要对健康检查端点进行限流 — 监控系统会误报
2. 绝不要仅使用客户端提供的标识符作为限流键 — 极易被伪造
3. **绝不要在限流时返回 200 OK** — 客户端必须知道请求已被限流
4. 绝不要在未测量实际流量的情况下设置限流 — 会导致合法用户被阻断或限流值过高无效
5. 绝不要在无关租户之间共享计数器 — 避免“噪音邻居”问题
6. 绝不要跳过内部 API 的限流 — 行为异常的内部服务可能拖垮共享基础设施
7. 绝不要在未记录日志的情况下实现限流 — 缺乏可见性将影响限流调优和滥用检测