大规模恶意请求下API速率限制分层设计，关键不是给所有请求设同一个上限，而是分别回答两个问题：某个调用方能发多少请求，某类接口能承受多少请求。前者限制单个用户或凭证的影响范围，后者保护共享资源，二者配合才能兼顾防护效果与正常使用。
先分清两种限流边界
用户级：约束单个调用方
用户级限流按账号、API密钥或已认证的租户标识计数。它适合控制单个调用方的突发流量，避免某个凭证被滥用时挤占其他用户的服务能力。未登录请求可按可信的客户端标识或来源地址辅助限流，但地址可能被共享或轮换，不宜作为唯一身份依据。
接口级：保护具体资源
接口级限流按路由或操作类型设置上限。例如，读取公开信息的接口通常比发送验证码、创建订单或执行复杂查询更容易扩展；后几类操作可能占用外部服务、数据库连接或计算资源，应采用更严格的限制。接口级规则也能挡住大量不同账号同时请求同一高成本操作的情况。
可将规则理解为两道门：请求必须同时满足用户额度与接口容量。常见实现包括令牌桶和滑动窗口。令牌桶允许短暂突发，适合流量有自然波动的场景；滑动窗口能较平滑地控制一段时间内的请求数，但计数与存储成本需结合部署方式评估。
把规则从业务差异中推导出来
不要先拍一个适用于所有接口的数字。先观察正常流量的峰值、请求耗时、失败率和后端资源占用，再按接口成本分组。对耗时短、可缓存的读取操作，可以设置相对宽松的额度；对会触发短信发送、写入或昂贵计算的操作，则应降低突发额度，并设置更短的恢复窗口。
初始配置可以从每秒与每分钟两个时间尺度试起，再通过压测和真实流量调整。具体额度没有通用标准：请求体大小、后端容量、缓存命中率和用户分布都会改变结果。若规则以“每用户每分钟请求数”表达，必须同时考虑短时间突发；只限制分钟总量，仍可能让请求在几秒内集中到达。
按步骤上线，降低误伤风险
- 梳理接口。列出身份识别方式、资源成本和业务影响，标记登录、写入、外部调用等敏感操作。
- 建立基线。统计正常请求的峰值与分位数，并区分高频用户、自动化客户端和匿名流量；避免把攻击期间的异常峰值当成正常额度。
- 配置双层规则。先设置用户级额度，再为高成本接口配置独立的接口级上限。不同租户可按合同或实际服务能力分档，但规则应可审计。
- 灰度观察。先记录哪些请求会被拒绝，观察误拦截、延迟和后端负载，再逐步启用拦截。限流响应可返回 HTTP 429，并在适用时提供 Retry-After，帮助客户端延后重试。
- 持续校准。监测限流命中数、429比例、接口延迟及资源使用。若大量正常调用被挡，应检查身份键、客户端重试和额度；若后端仍过载，则应调整接口上限或增加容量，而非只提高用户额度。
分层配置的取舍与边界
只做用户级限流，配置直观，却难以阻止多个账号共同压垮昂贵接口；只做接口级限流，能保护资源，但一个高频调用方可能消耗该接口的大部分共享额度。分层方案更精细，也会增加规则维护、计数存储和排障复杂度。用户身份不稳定、计数器跨节点不一致，或客户端遇到429后立即重试，都可能削弱效果。
因此，大规模恶意请求下API速率限制分层设计应与认证、缓存、队列和异常流量处置配合，而不是替代它们。对关键写操作，还应考虑幂等处理；对可延后任务，可通过队列削峰。合理的限流目标是控制单个调用方的影响，同时守住接口容量边界，并给正常流量留下可解释的恢复路径。
常见问题
用户级额度应该按账号还是API密钥计算？
优先选择稳定、可追责的身份标识。若密钥可轮换或多个密钥属于同一租户，可在租户级汇总，并保留密钥级观测。
触发限流后客户端应如何处理？
客户端应识别429，遵循Retry-After（若有），并采用带随机抖动的退避重试；不要立即重复发送相同请求。
限流会取代熔断吗？
不会。限流控制进入系统的请求速率；熔断通常在下游故障或持续失败时暂时阻断调用，二者保护的阶段和目的不同。
