CLOUD云知道
IP 访问限频（Rate Limiting）的 QPS（Queries Per Second）阈值没有统一的“标准答案”，它完全取决于你的业务场景、用户行为特征以及系统架构承受能力。
设置过高会导致接口被刷爆或成本失控，设置过低则会导致正常用户频繁报错（429 Too Many Requests）。以下是针对不同场景的推荐策略和配置思路：
1. 常见场景参考值
根据经验，不同业务类型的合理 QPS 范围如下（以单个 IP 为单位）：
| 业务场景 | 推荐单 IP QPS | 适用说明 |
|---|---|---|
| 普通静态资源/图片 | 50 – 200 | 用户浏览页面时加载多个资源，但不会瞬间高频请求。 |
| API 查询接口 (如搜索、列表) | 10 – 30 | 用户手动操作频率较低，通常 1-2 秒一次点击。 |
| 核心交易/登录/注册 | 3 – 5 | 安全性要求高，防止暴力破解和撞库攻击。 |
| 短信验证码/邮件发送 | 1 – 3 | 极严格限制，防止恶意群发骚扰。 |
| 爬虫/数据抓取防护 | 1 – 5 | 针对非人类行为的防御性限制，正常用户极少达到此频率。 |
| 内部微服务调用 | 不限 或 极高 | 如果是内网互调，通常不限制 IP，而是限制整体流量或依赖熔断机制。 |
注意：以上数值仅为起始建议值。对于高并发互联网应用（如电商大促），可能需要更精细的分级策略。
2. 如何科学制定你的阈值？
不要盲目照搬，建议按照以下步骤进行测算和调整：
A. 基于用户行为分析（最准确）
查看历史日志，统计95% 或 99% 的正常用户在高峰期的最大 QPS。
- 方法：提取过去一周的访问日志，按 IP 分组，计算每个 IP 在任意 1 秒内的最大请求数。
- 设定原则：将阈值设定在比”99% 正常用户最大值”略高的位置（例如正常用户最高是 8 QPS，你可以设为 10 QPS），留出安全余量。
B. 考虑设备与网络环境
- NAT 网关影响：如果大量用户通过公司出口、学校校园网或家庭路由器上网，这些用户的出口 IP 是共享的。必须降低阈值（例如从 10 降至 2-3），否则会导致整个网段的用户无法访问。
- 移动端 vs PC 端：App 端通常有 Token 验证且更新快，PC 端浏览器缓存多。可以针对 User-Agent 区分限频策略。
C. 结合 Redis 等中间件特性
限频通常配合 Redis 的 INCR + EXPIRE 实现（令牌桶或漏桶算法）。
- 时间窗口选择：
- 1 秒窗口：防突发攻击，但对网络抖动敏感，容易误杀。
- 60 秒窗口：适合平滑流量，用户体验更好，但无法拦截瞬时高频攻击。
- 混合策略：建议同时配置“每秒级”和“分钟级”两个维度。例如：单 IP 每秒不超过 5 次，每分钟不超过 100 次。
3. 实施建议与最佳实践
分层限频策略：
- 全局限频：限制整个系统的总 QPS（保护数据库不被打挂）。
- 单 IP 限频：防止恶意刷量。
- 单用户 ID 限频：即使换了 IP，同一账号也不能无限请求（需配合登录态）。
动态调整与灰度发布：
- 初期宁低勿高。先设置为保守值（如 5 QPS），观察业务反馈。
- 如果收到大量用户投诉（429 错误），再逐步上调阈值。
- 利用监控工具（如 Prometheus + Grafana）实时观察
rate_limit_exceeded的错误率。
友好的错误处理：
- 当触发限频时，返回标准的 HTTP 429 状态码。
- 在响应头中增加
Retry-After字段，告知客户端多久后可以重试，提升体验。 - 前端应做好降级处理（如显示“请求过于频繁，请稍后再试”，而不是直接崩溃）。
白名单机制：
- 务必为内部运维 IP、合作伙伴 IP、CDN 回源 IP 配置白名单，避免误伤正常业务逻辑。
总结
如果你需要一个通用的起步值：
- 对于公开 API，建议从 10 QPS / 秒 开始。
- 对于敏感操作（登录、支付），建议从 3 QPS / 秒 开始。
最终请务必通过压测和线上数据分析来校准这个数值。