Node.js 限流与并发控制：从简单并发到分布式防护

在构建高可用的 Node.js 应用时，控制“速度”至关重要。这通常分为两个场景：一是** outbound（出站），即我们要控制自己调用第三方 API 的频率，避免被封禁；二是 inbound（入站）**，即我们要限制用户对我们的服务器发起请求的频率，防止服务过载。

本文对比的六个包涵盖了这两个场景的不同需求。让我们深入看看它们在实际工程中是如何工作的。

🚦 核心定位：并发控制 vs 速率限制

首先必须明确一个概念：并发控制（Concurrency Control） 和 速率限制（Rate Limiting） 是不同的。

• 并发控制 关注的是“同一时刻最多有多少个任务在运行”。
• 速率限制 关注的是“单位时间内最多允许多少个请求”。

p-limit 是典型的并发控制工具，而 express-rate-limit 和 rate-limiter-flexible 则是典型的速率限制工具。bottleneck 则是两者的集大成者。

🏃 出站流量：调用第三方 API 的最佳实践

当你需要调用外部 API（例如抓取数据、发送邮件）时，直接发起请求往往会导致被对方服务器拒绝（HTTP 429）。这时你需要一个能够“排队”并“平滑发送”请求的工具。

1. p-limit：最简单的并发锁

如果你只需要限制同时运行的任务数量，而不关心时间窗口，p-limit 是最轻量的选择。

import pLimit from 'p-limit';

// 限制同时只有 2 个任务运行
const limit = pLimit(2);

const input = [1, 2, 3, 4, 5];

// 映射所有任务，但它们会排队执行
const result = await Promise.all(input.map(async (val) => {
  return limit(() => {
    console.log(`Starting task ${val}`);
    return fetch(`https://api.example.com/data/${val}`);
  });
}));

适用场景：前端图片懒加载、简单的脚本批量处理。它没有内置的延迟机制，只是单纯地暂停启动新任务。

2. bottleneck：智能作业调度器

bottleneck 远不止是限制并发。它能模拟“令牌桶”或“固定窗口”，自动计算何时发送下一个请求，甚至支持优先级队列。

import Bottleneck from 'bottleneck';

// 配置：每 1000ms 最多运行 5 个任务，且任务之间至少间隔 200ms
const limiter = new Bottleneck({
  minTime: 200, 
  maxConcurrent: 5,
  highWater: 100, // 队列长度警告阈值
  strategy: Bottleneck.strategy.OVERFLOW // 队列满时的策略
});

// 提交任务
limiter.schedule(() => fetch('https://api.github.com/users'), { priority: 1 })
  .then(res => console.log('Done'));

// 监听队列状态
limiter.on('highwater', () => {
  console.warn('队列积压过多，考虑降低发送速度');
});

适用场景：调用 Stripe、GitHub、Google Maps 等有严格速率限制的 API。它能保证你的请求曲线是平滑的，而不是突发式的。

3. limiter：老派的令牌桶

limiter 是一个较老的库，它实现了经典的令牌桶算法。虽然功能可靠，但其 API 设计偏向回调风格，对 Promise 的支持不如前两者自然。

import { TokenBucket } from 'limiter';

// 每 1000ms 补充 1 个令牌，桶容量为 5
const bucket = new TokenBucket(1, 1000, null, 5);

bucket.removeTokens(1, (err, remainingTokens) => {
  if (err) throw err;
  // 拿到令牌后执行请求
  fetch('https://api.example.com/data');
  console.log(`剩余令牌: ${remainingTokens}`);
});

适用场景：维护旧项目，或者需要精确控制令牌补充速率且不喜欢 bottleneck 复杂配置的场景。在新项目中，通常推荐 bottleneck。

🛡️ 入站流量：保护你的服务器

当面对用户请求时，你需要防止单个 IP 或用户刷爆你的接口。

4. express-rate-limit：Express 的标准卫士

这是 Express 生态中最流行的中间件。它默认使用内存存储，配置简单，足以应对大多数单体应用。

import rateLimit from 'express-rate-limit';

const limiter = rateLimit({
  windowMs: 15 * 60 * 1000, // 15 分钟窗口
  max: 100, // 每个 IP 最多 100 次请求
  message: '请求过于频繁，请稍后再试',
  standardHeaders: true, // 返回 RateLimit-* 头
  legacyHeaders: false,
});

app.use('/api/', limiter);

适用场景：标准的 Express 后端，单实例部署。如果你的应用部署在多个实例上且没有共享存储（如 Redis），每个实例会独立计数，可能导致限制不精确。

5. rate-limiter-flexible：分布式系统的利器

当你的应用部署在多个容器或服务器（集群模式）时，内存存储就不再可靠了。rate-limiter-flexible 支持 Redis、Memcached 等多种后端，确保全局限流一致。

import { RateLimiterRedis } from 'rate-limiter-flexible';
import Redis from 'ioredis';

const redisClient = new Redis();

const limiter = new RateLimiterRedis({
  storeClient: redisClient,
  keyPrefix: 'middleware',
  points: 10, // 10 次请求
  duration: 1, // 每 1 秒
});

// 在中间件中使用
app.use(async (req, res, next) => {
  try {
    await limiter.consume(req.ip);
    next();
  } catch (rejRes) {
    res.status(429).send('Too Many Requests');
  }
});

适用场景：微服务架构、高并发系统、需要精确全局限流的场景。它也支持非 Express 环境（如 Koa、NestJS 或纯 HTTP 模块）。

6. ratelimiter：⚠️ 已弃用，请勿使用

ratelimiter 曾经是一个流行的通用限流库，但目前已正式弃用（Deprecated）。其维护者建议所有用户迁移到 rate-limiter-flexible。

// ❌ 不要在新项目中这样做
// const Limiter = require('ratelimiter'); 
// 该包不再接收安全更新，且缺乏现代存储适配

建议：如果你正在使用它，请制定计划迁移到 rate-limiter-flexible，以获得更好的性能和安全性。

📊 深度对比总结

💡 架构师建议

1. 调用第三方 API：毫不犹豫选择 bottleneck。它的 minTime 和 maxConcurrent 组合能完美模拟大多数 API 的速率限制策略，且内置的队列管理能防止内存溢出。
2. 简单的脚本/前端任务：使用 p-limit。它体积极小，没有多余依赖，解决“同时只能跑 5 个”这类问题绰绰有余。
3. Express 单体应用：使用 express-rate-limit。配置最简单，文档最丰富，能满足 90% 的防刷需求。
4. 微服务/高并发集群：必须使用 rate-limiter-flexible 配合 Redis。只有共享存储才能保证在水平扩展时限流规则依然有效。
5. 遗留系统：如果遇到 limiter，理解其令牌桶逻辑即可；如果遇到 ratelimiter，请尽快替换。

限流不仅仅是加个锁，它是系统稳定性的基石。选择正确的工具，能让你的应用在流量洪峰中依然稳如泰山。