个人开发学习资料库

Appearance

别让你的接口"裸奔":前端全栈开发者必懂的限流算法 ​

更新: 9/25/2026 字数: 0 字 时长: 0 分钟

一、开篇:那些让全栈开发者夜不能寐的"雪崩"时刻 ​

作为写 Node.js 的全栈开发者,你多半亲历过这些场景:

  • 大促当天,秒杀接口 QPS 瞬间飙到 5 万,数据库连接池瞬间打满,整个站点 502
  • 前端某个组件写了个 useEffect 没加依赖数组,导致同一个接口每秒调用几十次
  • 爬虫或者恶意用户拿脚本疯狂调你的 /api/login,CPU 直接飙到 100%
  • 第三方支付回调重试太猛,把你的 Webhook 服务打挂了
  • 前端搜索框忘了防抖,用户每敲一个字都发一次请求,后端日志被刷屏

这些问题的答案,都指向同一个关键词 —— 限流(Rate Limiting)。

限流概念示意图

限流不是"少接客",而是让服务在可承受的负载下持续稳定运行。理解和运用限流算法,是全栈开发者从"能跑就行"迈向"生产可用"的分水岭。

二、什么是限流?一个心智模型 ​

限流的本质:在单位时间内,限制某个资源(API、CPU、带宽等)的最大访问次数,超过限制的请求要么被拒绝、要么被延迟、要么被排队。

三、核心算法逐个击破 ​

3.1 固定窗口计数法(Fixed Window) ​

固定窗口计数法原理示意图

原理 ​

把时间切成固定长度的窗口(如每秒/每分钟),每个窗口内维护一个计数器,超过阈值就拒绝。

Node.js 实现 ​

javascript
class FixedWindowLimiter {
  constructor(limit, windowMs) {
    this.limit = limit;         // 阈值
    this.windowMs = windowMs;   // 窗口大小
    this.counters = new Map();  // key -> { count, resetAt }
  }

  allow(key) {
    const now = Date.now();
    const bucket = this.counters.get(key);

    if (!bucket || now >= bucket.resetAt) {
      // 新窗口
      this.counters.set(key, { count: 1, resetAt: now + this.windowMs });
      return true;
    }

    if (bucket.count < this.limit) {
      bucket.count++;
      return true;
    }
    return false;
  }
}

// 使用:每个 IP 每秒最多 10 次
const limiter = new FixedWindowLimiter(10, 1000);
app.use((req, res, next) => {
  if (!limiter.allow(req.ip)) return res.status(429).json({ msg: 'Too Many Requests' });
  next();
});

优缺点 ​

  • ✅ 实现简单,内存和计算开销都小
  • ❌ 临界突刺问题:窗口边界处可能瞬间通过 2 倍流量(如 0.999s 通过 10 个,1.001s 又通过 10 个,1 秒内实际过了 20 个)

适用场景 ​

对精度要求不高、简单的接口频率控制,如后台管理页面。

3.2 滑动窗口计数法(Sliding Window) ​

原理 ​

把大窗口切成多个小格子,统计最近 N 个格子的总数,窗口随时间平滑滑动,解决固定窗口的临界突刺。

Node.js + Redis 实现(基于 ZSET) ​

javascript
const Redis = require('ioredis');
const redis = new Redis();

async function slidingWindowAllow(key, limit, windowMs) {
  const now = Date.now();
  const windowStart = now - windowMs;
  const member = `${now}-${Math.random()}`;

  const pipeline = redis.pipeline();
  pipeline.zremrangebyscore(key, 0, windowStart); // 清理过期
  pipeline.zadd(key, now, member);                // 记录当前请求
  pipeline.zcard(key);                            // 计数
  pipeline.pexpire(key, windowMs);
  const results = await pipeline.exec();
  const count = results[2][1];

  return count <= limit;
}

// 使用:每个用户每分钟最多 100 次
if (!(await slidingWindowAllow(`u:${userId}`, 100, 60_000))) {
  return res.status(429).end();
}

优缺点 ​

  • ✅ 精度高,平滑处理边界
  • ❌ 内存开销略大(需要存储每次请求的时间戳)

适用场景 ​

对突刺敏感的场景,如登录接口防刷、短信验证码防轰炸。

3.3 漏桶算法(Leaky Bucket) ​

漏桶算法原理示意图

原理 ​

请求像水一样流入桶中,桶以固定速率向外漏水(处理请求),桶满则拒绝新请求。核心目标是平滑输出。

Node.js 实现 ​

javascript
class LeakyBucket {
  constructor(capacity, leakRatePerSec) {
    this.capacity = capacity;
    this.leakRate = leakRatePerSec;
    this.water = 0;
    this.lastLeak = Date.now();
  }

  allow() {
    const now = Date.now();
    const elapsed = (now - this.lastLeak) / 1000;
    // 先漏水
    this.water = Math.max(0, this.water - elapsed * this.leakRate);
    this.lastLeak = now;

    if (this.water < this.capacity) {
      this.water++;
      return true;
    }
    return false;
  }
}

const bucket = new LeakyBucket(100, 10); // 容量100, 每秒漏10个

优缺点 ​

  • ✅ 输出速率恒定,后端负载极其平稳
  • ❌ 不允许突发,不适合"平时低峰、偶尔突发"的业务

适用场景 ​

流量整形(Traffic Shaping)、短信/邮件发送队列、对下游第三方 API 严格限速的场景。

3.4 令牌桶算法(Token Bucket) ​

令牌桶算法原理示意图

原理 ​

系统以恒定速率往桶里放令牌,请求需要拿到令牌才能通过。桶有容量上限,允许一定程度的突发(桶里堆积的令牌可以被一次性消费)。

Node.js 实现 ​

javascript
class TokenBucket {
  constructor(capacity, refillPerSec) {
    this.capacity = capacity;
    this.refillRate = refillPerSec;
    this.tokens = capacity;
    this.lastRefill = Date.now();
  }

  allow(cost = 1) {
    const now = Date.now();
    const elapsed = (now - this.lastRefill) / 1000;
    // 先补充令牌
    this.tokens = Math.min(this.capacity, this.tokens + elapsed * this.refillRate);
    this.lastRefill = now;

    if (this.tokens >= cost) {
      this.tokens -= cost;
      return true;
    }
    return false;
  }
}

// 平均 10 RPS, 允许瞬时突发 100 个请求
const bucket = new TokenBucket(100, 10);

直接用现成库:bottleneck / express-rate-limit ​

javascript
const rateLimit = require('express-rate-limit');

app.use('/api/', rateLimit({
  windowMs: 60 * 1000,
  max: 100,
  standardHeaders: true, // 返回 RateLimit-* headers
  message: { code: 429, msg: 'Too many requests' },
}));

优缺点 ​

  • ✅ 允许一定突发,同时保证平均速率,业界最常用
  • ❌ 实现稍复杂,分布式场景需借助 Redis + Lua

适用场景 ​

绝大多数 API 限流的默认选择:Nginx、AWS API Gateway、Kong 都用它。

3.5 四种算法一图对比 ​

算法平滑度突发支持实现复杂度内存开销推荐场景
固定窗口低弱⭐极小简单后台限频
滑动窗口中弱⭐⭐⭐较大精准防刷
漏桶高无⭐⭐小严格平滑输出
令牌桶中强⭐⭐小通用 API 限流

四、拓展:限流在实战项目中怎么落地? ​

限流在 Web 全栈开发中的多层级应用架构

4.1 前端限流:第一道防线 ​

前端限流的目标不是"安全"(客户端代码可被绕过),而是优化体验和减少无效请求。

防抖(Debounce):搜索框、resize 事件 ​

javascript
function debounce(fn, delay = 300) {
  let timer = null;
  return (...args) => {
    clearTimeout(timer);
    timer = setTimeout(() => fn(...args), delay);
  };
}
input.addEventListener('input', debounce(handleSearch, 300));

节流(Throttle):滚动、mousemove ​

javascript
function throttle(fn, interval = 200) {
  let last = 0;
  return (...args) => {
    const now = Date.now();
    if (now - last >= interval) {
      last = now;
      fn(...args);
    }
  };
}

按钮防重:提交订单最常见坑 ​

javascript
async function handleSubmit() {
  if (submitting.value) return;
  submitting.value = true;
  try {
    await api.createOrder();
  } finally {
    submitting.value = false;
  }
}

4.2 Node.js 单机限流 ​

  • express-rate-limit:最流行,支持内存/Redis 存储
  • bottleneck:功能全面,支持优先级、队列、集群
  • rate-limiter-flexible:高性能,支持多种后端

4.3 API 网关限流(推荐生产用法) ​

生产环境不要把限流只做在应用层,应下沉到网关:

  • Nginx limit_req_zone(基于漏桶)
  • Kong / APISIX(Lua 插件,基于令牌桶)
  • 云厂商网关:AWS API Gateway、阿里云 API 网关

4.4 分布式限流:Redis + Lua 是主流方案 ​

单机限流在多实例部署下会失效(每个实例各有一个计数器),必须使用共享存储:

javascript
// 令牌桶的 Redis Lua 脚本(原子操作)
const script = `
  local key = KEYS[1]
  local capacity = tonumber(ARGV[1])
  local rate = tonumber(ARGV[2])
  local now = tonumber(ARGV[3])
  local requested = tonumber(ARGV[4])

  local bucket = redis.call('HMGET', key, 'tokens', 'last')
  local tokens = tonumber(bucket[1]) or capacity
  local last = tonumber(bucket[2]) or now

  local delta = math.max(0, now - last) / 1000
  tokens = math.min(capacity, tokens + delta * rate)

  local allowed = tokens >= requested and 1 or 0
  if allowed == 1 then tokens = tokens - requested end

  redis.call('HMSET', key, 'tokens', tokens, 'last', now)
  redis.call('EXPIRE', key, 60)
  return allowed
`;

await redis.eval(script, 1, `rl:${userId}`, 100, 10, Date.now(), 1);

4.5 限流 + 熔断 + 降级 三剑客 ​

三者常配合使用,构成完整的服务保护体系:

  • 限流:控制入口流量
  • 熔断(如 opossum):下游连续失败时主动切断调用
  • 降级:返回兜底数据保证可用性(如返回缓存、静态默认值)

五、决策指南:什么场景选什么算法? ​

场景推荐算法备注
内部管理后台粗粒度限频固定窗口简单够用
登录/注册接口防暴力破解滑动窗口精准防边界突刺
通用 API 网关限流令牌桶允许突发,业界默认
对接第三方限速 API(短信/支付)漏桶严格恒速
秒杀/抢购令牌桶 + 前置排队配合 Redis + MQ
前端交互优化防抖/节流UX 优先
微服务集群限流令牌桶 + Redis Lua分布式共享状态

六、常见问题与排查 ​

问题原因解决方案
集群下限流不生效各实例独立计数改用 Redis 分布式限流
429 触发过于频繁阈值设置过低 or 未按用户维度隔离分维度限流(IP/UID/API Key)
时钟不同步导致误判多机 Date.now() 有偏差使用 Redis 服务器时间 TIME
内存持续增长key 未过期计数器加 TTL
用户体验差直接返回 429加 Retry-After header + 前端友好提示
突发流量误伤用漏桶太严格换令牌桶 + 合理桶容量

标准限流响应示例 ​

javascript
res.status(429)
  .set('Retry-After', '30')
  .set('X-RateLimit-Limit', '100')
  .set('X-RateLimit-Remaining', '0')
  .set('X-RateLimit-Reset', String(Math.ceil(resetAt / 1000)))
  .json({
    code: 'RATE_LIMITED',
    message: '请求过于频繁,请稍后再试',
    retryAfter: 30,
  });

前端拿到 429 后,应展示"请稍后再试"并禁用按钮 30 秒,而不是把红色错误抛给用户。

七、结语 ​

限流不是可有可无的"性能优化",而是服务稳定性的底线。从前端防抖到 Node.js 中间件、再到 API 网关、再到分布式 Redis Lua,每一层都值得投入。

写完接口不要急着上线,先问自己三个问题:

  1. 这个接口的 QPS 上限是多少?超过会怎样?
  2. 我用了什么算法限流?是否覆盖了单机 + 集群?
  3. 超限后前端能友好降级吗?

想清楚这三点,你就已经领先大多数只会写 CRUD 的开发者了。