如何找出有问题的高并发限流器代码中的错误？

## 作用 排查高并发限流器在单机测试正常、多机部署后异常的问题，重点识别局部正确但整体超限的并发控制错误。 ## 原理 ### 陷阱一：把全局限流配额误当成单机配额 - 限流额度通常按应用（如 AppKey）维度计算，而不是按每个实例计算。 - 如果每个实例都允许每秒 N 次请求，部署 3 个实例后，总请求量会变成 3N。 - 单机测试时只有一个实例，因此不会暴露问题；多机部署后才会触发全局限流。 - 应使用集中式限流或按实例数重新分配配额，确保所有实例合计不超过全局阈值。 ### 陷阱二：重试缺少抖动，引发重试风暴 - 请求被限流后，如果所有实例立即按固定节奏重试，会在同一时间再次集中发起请求。 - 这会放大流量压力，形成“重试风暴”。 - 重试应加入随机抖动、退避等待，并限制重试次数。 ### 陷阱三：混淆“限流”和“故障”的处理方式 - 限流表示请求过多，客户端应当降速。 - 故障表示服务暂时不可用，客户端通常应等待后再恢复。 - 如果把限流当成普通故障立即重试，会进一步加大系统压力。 - 对限流响应应采用降速、退避等差异化处理逻辑。 ### 陷阱四：只限制入口流量，忽略内部请求放大 - 一个外部请求可能在系统内部触发多个下游请求。 - 即使入口流量看起来没有超限，内部调用也可能因扇出、批量查询或重试而放大。 - 限流不能只设置在入口，还需要关注内部调用链路，在关键依赖处精准设闸。

## 作用 用于排查高并发场景下接口限流器“看似配置了却不生效”的问题，重点确认： - 限流中间件是否真正进入请求链路； - 限流策略是否被路径、注册顺序或前置逻辑绕过； - 多实例部署时计数状态是否共享； - 限流 key 是否稳定、唯一； - Redis 等存储后端是否可用、过期时间是否正确。 ## 原理 ### 1. 检查中间件是否真正执行 - 限流中间件必须注册在业务路由之前，否则请求可能已经被路由处理，限流不会生效。 - 检查路径匹配规则，例如配置的是 `/api/**`，实际请求却是 `/v1/user`，会导致规则无法命中。 - 检查鉴权、日志等前置中间件是否提前 `return res.send()`，或调用 `next('route')` 跳过限流逻辑。 ### 2. 检查限流存储是否可靠 - 高并发或多实例部署时，不能使用默认的 `MemoryStore`，因为各进程内存不共享，会导致计数分散。 - 应使用 Redis 等分布式存储，并检查客户端是否处于 ready 状态。 - 记录 `store.incr()` 的返回值，确认计数确实递增。 - Redis key 的 TTL 必须和限流窗口一致。例如窗口为 60 秒，key 却 30 秒过期，就会导致计数频繁重置。 - 需要监听 Redis 连接异常，避免存储失败时限流被静默绕过。 ### 3. 检查限流 key 是否稳定 - 如果按 IP 限流，需要正确处理反向代理，优先从 `X-Forwarded-For` 获取第一个非内网地址，不能只依赖 `req.ip`。 - 如果按用户限流，应确保 token 解析在限流之前完成，并正确挂载 `req.userId`。 - 不要使用动态 header 或不稳定字段生成 key，否则同一用户会被分散成多个计数。 - 可临时打印限流 key，对比同一客户端的多次请求是否生成相同 key。 - Redis key 应使用统一前缀，例如 `rl:`，避免和其他业务 key 冲突。 ### 4. 典型错误与修复方向 错误写法通常存在以下问题： - 使用默认内存存储，集群或多进程下无法共享计数； - 没有处理 Redis 连接异常； - 没有自定义稳定的 `keyGenerator`； - 没有明确返回 `429 Too Many Requests`。 修复时应： - 显式配置 `RedisStore`； - 等待 Redis 连接成功后再启动服务； - 监听 Redis `error` 事件； - 使用 `user ID + 可信 IP` 的兜底策略生成稳定 key； - 保持 `windowMs` 与 Redis key 过期时间一致； - 在触发限流时明确返回 HTTP 429。